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FOREWORD 


The  Army  Research  Institute  for  the  Behavioral  and  Social  Sciences  (ARl) 
maximizes  combat  effectiveness  through  research  in  the  acquisition,  develop¬ 
ment,  training,  and  utilization  of  soldiers  in  military  systems.  The  ARl  Field 
Unit  at  Fort  Leavenworth  supports  the  Combined  Arms  Center  by  developing  re¬ 
search  products  designed  to  increase  the  combat  effectiveness  of  command 
groups  and  command  staff  operations  by  improving  command  and  control  perfor¬ 
mance  capabilities.  Of  special  interest  is  research  in  the  use  of  automation 
to  improve  command  and  control  operations. 

The  Combined  Arms  Center  is  responsible  for  integrating  efforts  to  develop 
automated  command  and  control  systems,  to  include  informal  efforts,  character¬ 
ized  as  field  unit  initiatives.  Such  field  unit  initiatives  have  made  a  sig¬ 
nificant  contribution  to  the  initial  development  of  the  tactical  portions  of 
the  Army  Command  and  Control  System  (ACCS).  As  the  ACCS  systems  are  fielded, 
the  need  for  user  initiative  continues ,  both  to  determine  the  optimal  use  of 
the  systems  and  to  aid  in  their  evolutionary  development.  This  manual  provides 
guidance  to  assist  field  unit  users  in  these  tasks.  The  guidelines  presented 
were  designed  to  assist  field  users  in  smoothing  the  transition  to  new  systems 
by  providing  insights  into  the  problem  of  building  man-machine  systems  that 
take  full  advantage  of  all  system  components ,  and  by  providing  tools  to  be  used 
to  accomplish  the  necessary  system  integration.  -  _ _ 

The  application  of  principles  set  forth  in  this  document  will  assist  users 
to  achieve  more  quickly  the  improved  command  and  control  performance  standards 
inherent  in  Future  Battle  Doctrine. 
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CHAPTER  1:  INTRODUCTION 

Command  and  control  of  US  Army  units  has  historically  been  performed  in  a 
manual  mode.  Command  and  control  has  included  voice  and  message  traffic  for 
the  passage  of  information,  and  manual  correlation  of  information  in  command 
posts,  corps  through  brigade.  There  is  more  information  about  the  battlefield 
available  today  than  ever  before,  yet  the  staff  processes  information  essen¬ 
tially  as  it  always  has.  While  the  existing  command  and  control  system  con¬ 
tains  some  time  saving  automated  procedures,  it  primarily  remains  a  system  of 
manual  procedures.  The  system  involves  repetitive  manual  entering,  transcrib¬ 
ing,  and  posting  of  data,  increasing  the  chances  for  error,  especially  in  a 
stressful  combat  situation.  This  system  has  evolved  in  an  environment  far  less 
dynamic  than  that  expected  to  exist  in  future  combat.  The  present  system  has 
serious  deficiencies  in  responsiveness,  survivability,  and  dependability  that 
would  preclude  timely  decision  making  by  commanders  and  staffs,  affecting  bat¬ 
tle  results  adversely. 

The  forces  of  the  Warsaw  Pact  represent  the  most  formidable  threat  to  the 
US  Army  in  the  forseeable  future.  Warsaw  Pact  forces  have  long  enjoyed  the 
advantages  of  numerical  superiority  over  the  forces  of  NATO.  The  margin  of 
this  superiority  is  increasing  and  will  continue  to  increase  into  the  next 
decade.  The  United  States  has  maintained  a  sizable  technological  advantage 
over  its  potential  adversaries,  and  it  is  likely  that  advantage  will  increase. 
Recent  advances  in  data  processing  technology  have  been  enormous  and,  without 
question,  future  developments  will  bring  computers  which  are  even  more  power¬ 
ful,  reliable,  compact,  and  economical.  The  challenge  which  faces  the  US  Army 
is  to  employ  that  technological  advantage  through  the  development  of  the  auto¬ 
mated  command  and  control  systems  which  will  allow  the  commander  to  fight  the 
battle  in  depth,  with  synchronization  and  agility,  and  to  exercise  the  quality 
and  responsive  command  and  control  necessary  to  fight  outnumbered  and  win. 

is  clear  that  the  employment  of  automation  will  play  an  increasing  role 
in  providing  the  means  of  control  and  in  supporting  the  execution  of  command  in 
the  Airland  Battle.  The  Army  is  investing  heavily  to  develop  and  procure  the 
appropriate  systems.  Army  Regulation  11-39  established  the  Army  Command  and 
Control  System  (ACCS)  and  prescribes  policy,  guidance  and  responsibility  for 
managing  the  evolutionary  development  of  the  Army's  entire  command  and  control 
system.  .The  responsibilities  of  the  ACCS  Architect  are  assigned  to  the  Com¬ 
mander  of  the  US  Army  Training  snd  Doctrine  Command  (TRADOC)  and  the  responsi¬ 
bilities  of  ACCS  System  Engineer  are  assigned  to  the  Commander  of  the  Army 
Material  Command  (AMC).  The  US  Army  Combined  Arms  Center  (CAC)  is  responsible 
for  the  coordination  of  the  Army  Command  and  Control  System  and  is  the  TRADOC 
proponent  for  command,  control,  communication,  8nd  intelligence  combat  develop¬ 
ments.  The  tactical  portion  of  ACCS  has  been  designated  as  the  Army's  Command, 
Control,  and  Subordinate  Systems  (CCS*).  The  next  chapter  of  this  book  in¬ 
cludes  a  discussion  of  Command,  Control,  and  Subordinate  Systems. 

The  field  unitA  will  not,  however,  simply  wait  for  the  fielding  of  the  ob¬ 
jective  systems  of  the  ACCS.  Field  unit  officers  sre  the  experts  in  tactical 
operations,  understand  their  current  procedures  completely,  and  will  be  the 
ultimate  users  of  the  system.  Their  contributions  during  its  development  will 
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be  vital  to  the  success  of  the  entire  program.  Further,  once  the  command, 
control,  and  subordinate  systems  are  fielded,  they  will  follow  an  evolutionary 
development,  the  success  of  which  depends  heavily  on  field  unit  user  initia¬ 
tive.  On  the  other  hand,  the  field  units  should  not  attempt  to  build  tactical 
systems  independently.  The  availability  of  relatively  Inexpensive  microcom¬ 
puters  in  the  commercial  market  has  led  to  a  prol 1 ferati on  of  such  attempts. 
Many  of  these  unit  initiative  systems  had  non-1 nteroperable  hardware  and  soft¬ 
ware  and  designs  which  were  inconsistent  with  the  emerging  ACCS  architecture. 
This  tends  to  greatly  restrict  the  value  of  such  independent  developments  to 
the  Army  as  a  whole  and  detracts  from  the  development  and  fielding  of  the  ob¬ 
jective  command  and  control  systems.  With  the  notable  exception  of  DCCS  (Dis¬ 
tributed  Command  and  Control  System)  developed  at  Fort  Lewis  and  discussed  in 
Chapter  2  of  this  manual,  unit  attempts  to  apply  automation  to  tactical  opera¬ 
tions  have  had  little  lasting  value.  Additionally,  because  they  do  not  take 
advantage  of  the  work  which  has  already  been  accomplished,  Independent  initi¬ 
atives  usually  involve  a  significant  duplication  of  effort.  Unit  automation 
initiative  is  strongly  encouraged  because  of  its  potential  value,  however,  it 
is  essential  that  the  effort  be  coordinated  through  the  responsible  Army 
agency.  When  the  object  of  automation  is  the  tactical  command  and  control 
system,  the  responsible  agency  is  the  Command,  Control,  Communications,  and 
Intelligence  Directorate  (C-^I)  of  the  Combined  Arms  Combat  Developments  Activ¬ 
ity  (CACDA)  at  Fort  Leavenworth. 

As  the  CCS**  control  systems  are  fielded,  the  field  units  will  play  an  im¬ 
portant  role  in  the  Army  automation  effort.  There  are  four  areas  of  activity 
which  comprise  that  field  unit  role. 

1.  Developing  Garrison  Applications.  The  unit  may  develop  applications, 
using  CCS2  equipment,  to  assist  garrison  operations.  Although  the  systems  have 
been  designed  for  tactical  operation  and  their  configuration  and  use  in  the  TOC 
have  been  established,  the  Individual  units  are  left  to  solve  the  problem  of 
how  to  reconfigure  and  use  the  equipment  in  their  unique  garrison  applications. 
Software  useful  for  this  purpose  is  provided  with  all  the  CCS2  control  systems. 
This  software  Includes  an  operating  system,  data-base  management,  communication 
processing,  user  tools,  (e.g.,  Lotus  and  Wordstar),  and  a  graphics  package.  The 
importance  of  field  unit  initiative  in  developing  garrison  applications  goes 
well  beyond  the  value  such  applications  would  have  for  aiding  garrison  opera¬ 
tions;  the  familiarity  with  the  equipment  gained  in  garrison  will  be  signifi¬ 
cant  when  the  equipment  is  put  to  tactical  use.  If  the  computers  just  go  in 
the  closet  when  th*  unit  returns  from  the  field,  the  "train! ng-retraini ng"  and 
"computer  anxiety"  problems  in  the  field  will  be  greatly  increased. 

2.  Guiding  the  Development  of  CCS  .  The  Maneuver  Control  System  (MCS)  and 
the  other  control  systems  of  CCS2  will  follow  an  evolutionary  method  of  devel¬ 
opment.  Field  units  will  have  the  opportunity  to  submit  recommendations  for 
modifications  to  the  system  developers  and,  each  year,  updated  versions  of  the 
systems  will  be  delivered  to  the  users.  This  allows  the  system  to  both  grow  in 
power  and  adjust  to  new  or  changed  tactical  requirements.  The  concept  for  the 
unit  role  in  evolutionary  development  goes  beyond  the  submission  of  proposals. 
Units  are  encouraged  to  develop  tactical  applications  using  the  CCS2  computers 
or  other  computers  which  exist  in  the  unit.  Tactical  systems  will  then  include 
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a  "formal"  component,  consisting  of  the  standardized  CCS  control  system  deliv¬ 
ered  to  all  the  units,  and  an  "informal"  component  developed  internally.  Ele¬ 
ments  of  the  informal  component,  having  been  refined  and  validated  by  field 
use,  may  later  be  Incorporated  in  future  editions  of  the  "formal"  component  and 
spread  Armywide.  As  recommended  earlier,  initiatives  in  the  tactical  arena 
should  be  coordinated  with  the  C^I  directorate  of  CACOA  at  Fort  Leavenworth. 

p 

3.  Restructuring  Operating  Procedures.  The  CCS  are  information  process¬ 
ing  systems;  they  will  change  the  speed,  the  amount,  and  the  organization  of 
the  information  which  flows  during  tactical  operations.  The  tactical  Or  system 
is  a  system  of  men  and  machines.  The  system  developers  have  defined  and  stan¬ 
dardized  the  operation  of  the  machine  component;  the  operation  of  the  human 
component  must  also  change.  The  task  which  confronts  the  fie,Ld  units  is  to 
change  their  operating  procedures  to  maximize  the  benefits  of  automation.  The 
accomodations  to  automation  in  such  areas  as  unit  SOP  and  task  assignment  will 
require  unit  effort  and  experimentation. 

4.  Incorporating  the  work  of  other  units.  Other  units  may  have  already 
developed  software  for  a  particular  military  purpose  and  your  unit  may  wish  to 
adapt  it  to  your  organization.  For  example,  both  the  Air  Force  and  the  XVIII 
ABN  CORPS  have  developed  relatively  powerful  computer  programs  to  assist  in 
aircraft  load  planning.  Although  these  programs  are  already  developed  and 
operating  there  are  several  tasks  required  before  they  could  be  transported  to 
your  unit,  including  the  preparation  of  a  concept  of  operation,  requirements 
definition,  and  a  careful  study  of  the  effects  on  unit  SOP,  task  assignment, 
etc.  Units  may  keep  abreast  of  developments  elsewhere  through  such  publica¬ 
tions  as  C2MUG,  published  by  the  Communicat Jons-Electronic  Command  (CECOM)  at 
Fort  Leavenworth  and  by  contacting  the  C^I  Directorate  of  CACDA  or  your  Automa¬ 
tion  Management  Office. 

This  manual  provides  Information  for  field  unit  officers  who  are  responsi¬ 
ble  for  managing  the  introduction  of  automation  into  command  and  control  func¬ 
tions.  It  is  designed  to  assist  in  the  four  tasks  described  above.  This 
document  does  not  address  the  technical  areas  of  programming  and  software 
design.  Rather,  it  addresses  issues  that  must  be  considered  in  exploiting 
capabilities  to  further  improve  command  and  control  operations.  In  addition 
to  basic  guidelines  for  organizing  the  effort,  the  manual  provides  guidance 
for  each  of  the  necessary  steps  in  implementing  an  effort  to  apply  automation 
to  tactical  or  garrison  operations.  These  steps  are:  concept  development, 
requirements  definition,  system  development,  and  demonstration  and  trials. 
Figure  1-1  illustrates  the  development  cycle. 

Chapter  2  of  this  manual  is  a  summary  of  the  Army  automation  effort  and  a 
description  of  the  tactical  portion  of  the  ACCS,  the  Command,  Control,  and 
Subordinate  Systems.  Chapter  3  gives  some  guidelines  for  organizing  the  auto¬ 
mation  effort.  These  basic  principles  were  discovered  by  field  unit  members  in 
USAREUR  and  CONUS  who  were  early  experimenters  with  C2  automation.  Chapter  4 
shows  how  to  make  flow  charts  of  information  processing  systems.  This  chapter 
also  provides  a  basis  for  estimating  the  potential  benefits  of  automation. 
Chapter  5  describes  the  process  of  concept  development  whereby  new  ideas  are 
transformed  into  detailed,  well-defined  and  analyzed  concepts.  Chapter  6 
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explains  a  method  for  systematically  identifying  the  information  flow  require¬ 
ments,  an  analysis  which  is  necessary  for  software  design.  Chapter  7  presents 
several  useful  principles  for  planning  and  conducting  the  demonstration  and 
trials,  and  for  promoting  the  continued  acceptance  of  automation  by  the  unit. 
Finally,  a  reference  list  is  included. 


CHAPTER  2:  THE  ARMY  AUTOMATION  EFFORT 

The  pace  of  battle  up  until  the  time  of  World  War  II  was  such  that  the 
commander,  aided  by  his  principal  staff,  could  gather  and  process  Incoming 
Information,  carefully  develop  hypotheses,  evaluate  the  various  options  availa¬ 
ble,  select  what  appeared  to  be  the  optimal  solution  snd  flesh  out  the  plans 
and  orders  for  Implementation.  This  situation  began  to  change  even  In  WWII. 
Increased  speed  of  both  ground  and  air  movement  coupled  with  Improved  communi¬ 
cations  began  to  tax  the  commander's  ability  to  accomplish  these  functions. 

This  In  turn  resulted  in  major  organizational  changes  in  each  of  the  services 
In  order  to  achieve  the  required  response  capabilities.  It  was  during  this 
time  that  the  concept  of  the  task  force  and  task  group  and  the  "fragmentary 
order"  procedure  were  developed  and  refined  to  cope  with  the  greater  fluidity 
of  operations. 

Since  WWII,  a  great  deal  of  new  technology  has  been  absorbed  into  the 
force.  These  capabilities  include: 

•  Increased  sensor  range  and  effectiveness. 

•  Increased  weapon  range  and  rates  of  fire. 

•  Greatly  improved  terminal  effects.  Including  tactical  nuclear  weapons. 

•  Terminal  guidance  (easing  the  target  location  problem). 

•  Vastly  Improved  capabilities  to  process  information  and  speed  its  flow 
in  closing  the  target-sensor  weapon  loop  (principally  in  the  Field 
Artillery  and  Air  Defense  Artillery  weapon  systems). 

•  Satellite  Communications  capability. 

•  Increased  communication  reliability. 

These  developments,  which  represent  the  most  significant  ones  since  the  end 
of  WWII,  are,  with  the  exception  of  the  final  two,  associated  with  the  object 
systems  or  the  "effectors"  of  the  force  as  opposed  to  the  "action  initiator"  or 
the  command  and  control  process.  John  H.  Cushman,  former  commanding  general  of 
the  Combined  Arms  Center  writes: 

Today,  except  for  such  modest  aids  as  Microfix,  the 
[G-2]  and  his  helpers  display  all  .  .  .  infc-mation  man¬ 
ually  -  -  on  sheets  of  paper,  on  acetate  with  grease 
pencils,  in  an  enemy  order-of-battle  book,  and  so  on. 

The  system  has  changed  hardly  at  all  since  1 917—1 8  *  a 
American  Expeditionary  Force  in  France. 
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The  wrap  leggings  of  the  AEF  exist  only  in  museums, 
but  the  intelligence  processing  methods  of  the  AEF  still 
exist  in  every  division  command  post  today. 

When  we  examine  the  technology  which  has  been  developed  in  recent  years  to 
improve  the  C2  system  we  find  the  following: 

•  Secure  FM  voice  radio.  This  made  a  substantial  contribution  to  reducing 
time  lines. 

•  Exponential  increase  in  communication  channels.  The  effect  of  this  has 
been  to  provide  more  raw  data  for  processing  but  has  hardly  speeded 
decision  making  and  has  certainly  added  to  the  electronic  signature 
problem. 

•  Replacement  of  tracing  paper  by  acetate.  This  increased  the  convenience 
factor  but  did  nothing  to  substantially  reduce  time  lines. 

These  technological  "fixes"  have  not  allowed  the  C  system  to  keep  pace 
with  combat  force  "effector"  capabilities  and  are  hardly  sufficient  to  concen¬ 
trate  forces  at  the  right  time  and  place  in  order  to  seize  the  initiative.  This 
fact  has  even  been  recognized  by  the  Soviets,  whose  doctrine  calls  for  a  more 
brute  force  and  mechanistic  mode  of  operations  (or  one  where  less  reliance  has 
to  be  placed  on  the  C2  element).  General  of  the  Army  S.M.  Shtemenko,  U.S.S.R. 
has  stated: 


The  volume  of  information  that  staffs  must  process 
has  increased  many  fold  since  World  War  II,  and  the  time 
allowed  for  decisionmaking  has  decreased  many  fold. 

As  a  result,  the  requirements  on  the  "brain  capacity" 
of  commanders  and  staffs  have  increased  vastly.  To  meet 
these  requirements  by  simply  extending  the  administrative 
operation  is  fundamentally  impossible.  The  only  escape 
from  this  incompatible  situation  lies  in  the  extensive 
application  of  automation,  primarily  computers  ...  a 
"man-machine"  system  is  more  perfect  than  "man”  alone  or 
"machine"  alone  .  .  .  Information  and  technology  does  not 
simply  help  the  commander  and  his  staff,  but  also  stimulates 
the  development  of  collective  military  creativity,  in  which 
the  largest  group  of  people,  including  those  separated  by 
great  distances,  can  participate.2 


^ J.H.  Cushman  (1985).  Command  and  Control  of  Theater  Forces:  The  Korean 
Command  and  Other  Cases.  Center  for  Information  Policy  Research,  Harvard 
University.  Cambridge,  Massachusetts. 

2V.V.  Druzhinin  and  D.S.  Koutorov  (1972).  Foreword  to  the  Russian  Edition  of 
Concept,  Algorithm,  Decision  (A  Soviet  Way),  by  S.M.  Shtemenko  (General  of  the 
Army,  U.S.S.R.)  Superintendent  of  Documents,  U.S.  Government  Printing  Office, 
Catalog  No.  0301.79:6,  Stock  No.  008-070-00344-9. 
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2.1.  The  TOS  Program 


The  first  twenty  years  of  the  Army  automation  effort  were  embodied  by  the 
TOS  program.  From  1 958—196 4  the  system  concept  was  called  F1ELDATA  and  was 
directed  at  the  field  army  level.  It  was  a  display-oriented  system  that  pro¬ 
vided  for  storage  and  retrieval  of  selected  information.  After  1964  the  ex¬ 
perimental  system  was  known  as  the  European  Tactical  Operations  System 

(EUROTOS)  and  was  directed  at  both  the  field  army  and  corps  levels.  The  con¬ 
cept  for  the  system  was  expanded  during  this  time  but  implementation  never 
passed  the  storage  and  retrieval  stage.  From  1970-1973  there  was  the  Develop¬ 
mental  Tactical  Operations  System  (DEVTOS).  The  DEVTOS  used  EUROTOS  hardware 
and  software  to  evaluate  automation  at  the  division  level.  The  Tactical  Opera¬ 
tions  System,  Operable  Segment  (T0S^>  (1971-1977)  was  also  a  division  level 
concept  but  used  militarized  hardware  (the  GNY-K12,  the  central  processor  for 
TACFIRE)  as  opposed  to  the  commercial  hardware  which  had  been  used  in  the  past. 
Selected  functional  areas  (operations  and  intelligence)  were  implemented,  but 
here  again  the  automated  functions  went  no  further  than  storage  and  retrieval 
of  unprocessed  information.  The  Division  TOS  (DTOS)  program  ran  between  1973 
and  1979  and  was  an  attempt  to  identify  functional  area  requirements  for  auto¬ 
mation.  Additionally,  military  hardware  development  was  initiated  and  alternate 
system  operational  configurations  were  explored  down  to  and  including  the  bat¬ 
talion  level.  The  formal  TOS  program  was  discontinued  by  the  Army  in  1979  as  a 
result  of  House  and  Senate  Defense  Appropriation  Committee  actions.  Congress 
correctly  perceived  that  the  TOS  program  was  going  nowhere  after  more  than  100 
million  dollars  had  been  spent.  The  appropriation  committee  did  not  delete  the 
research  and  development  funds  for  the  TOS,  a  signal  that  the  need  the  program 
was  intended  to  fill  was  still  viewed  as  being  a  valid  one.  It  was  on  this 
available  thread  that  the  Army  began  to  pull  together  its  efforts  in  the  com¬ 
mand  and  control  automation  arena.  In  the  late  70's  and  early  80's  senior  Army 
leadership  formalized  the  Army  Command  and  Control  System  (ACCS)  concept. 


2.2.  The  Distributed  Command  and  Control  System 

Before  presenting  the  details  of  ACCS  and  the  Command,  Control,  and  Subor¬ 
dinate  Systems,  two  other  significant  developments  which  occurred  during  the 
first  half  of  the  decade  will  be  addressed:  the  Distributed  Command  and  Con¬ 
trol  System  (DCCS)  and  the  Army  Command  and  Control  Initiatives  Program 
(TACIP).  DCCS  was  a  field  Initiative  developed  at  Ft.  Lewis,  Washington  by  the 
Army  Development  and  Employment  Agency  (ADEA)  and  tested  by  the  9th  Infantry 
Division.  Based  on  the  16-bit  Intel  Grid  ml crocomputers  and  a  videographics 
subsystem,  DCCS  provided  automation  support  for  command  and  staff  actions  and 
the  capability  to  organize  and  distribute  the  results  of  these  actions  among 
the  functional  elements  of  the  division.  Central  features  of  DCCS  were  force 
level  staff  Integration  capability,  data  base  management  with  replicated  data 
bases  to  Increase  survivability,  and  a  decision  graphics  package.  The  evolu¬ 
tionary  development  of  DCCS  was  discontinued  in  1985,  with  the  merger  of  DCCS 
and  the  Maneuver  Control  System  (MCS),  one  of  the  Command,  Control,  and  Subor¬ 
dinate  Systems. 
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2.3.  The  Army  Command  and  Control  Initiatives  Program 


The  TACIP  program  arose  from  a  need  to  coordinate  the  activity  of  the  many 
field  units  which  had,  on  their  own  initiative,  begun  to  apply  microcomputer 
technology  to  command  and  control  problems.  As  previously  mentioned,  many  of 
the  initiatives  had  non-interoperable  hardware  and  software,  and  were  inconsis¬ 
tent  in  design  with  the  ACCS  architecture.  Additionally,  there  was  no  struc¬ 
ture  to  allow  sharing  of  information  among  field  units  and  there  was  no  formal 
mechanism  which  would  allow  continuity  of  effort  and  long  term  stability  of 
initiatives.  The  US  Army  Combined  Arms  Center  recognized  the  potential  contri¬ 
bution  of  these  initiatives  and,  in  September  1982,  established  the  Army  Com¬ 
mand  and  Control  Initiatives  Program.  The  general  goals  of  TACIP  are  to  firm 
up  the  management  of  the  command  and  control  field  initiatives  and  to  integrate 
the  bottoms-up  approach  with  the  top-down  development  of  the  ACCS  implementa¬ 
tion  plan,  the  Army  Command  and  Control  Master  Plan  (AC2MP).  Specific  TACIP 
objectives  are: 

a.  Support  the  development  of  objective  command  and  control  systems  by 
aligning  field  initiatives  with  the  ACCS  architecture. 

b.  Encourage  and  support  user  involvement  in  defining  command  and  control 
system  requirements. 

c.  Coordinate,  resource,  and  evaluate  command  and  control  initiatives. 

d.  Collect,  coordinate,  and  integrate  field  experience  in  command  and 
control  initiatives  to  permit  better  definition  of  user  requirements. 

e.  Use  results  of  field  evaluations  8nd  experience  in  the  review  and  modi¬ 
fication  of  existing  requirements  documents. 

f.  Identify  and  recommend  command  and  control  systems  for  near  term  field¬ 
ing. 

g.  Disseminate  information  on  the  initiatives  to  Army  units  worldwide. 

h.  Facilitate  the  coordinated  transition  of  TACIP-generated  materiel  re¬ 
quirements  into  the  regulatory  US  Army  materiel  acquisition  process. 

During  1983  and  early  1984  TACIP  was  Involved  in  the  development,  fielding, 
funding,  and  evaluation  of  numerous  initiatives.  During  the  Command  and  Con¬ 
trol  System  Program  Review  (C2SPR)  II  held  in  July  1984,  the  question  was 
raised  as  to  whether  it  was  time  to  stop  the  "1000  flowers  blooming"  referring 
to  the  development  of  initiatives.  The  Vice  Chief  of  Staff  of  the  Army  decided 
that  the  effort  should  continue,  and  TACIP  should  increase  its  efforts  to 
gather  and  disseminate  information  on  the  initiatives.  At  this  time  (1985), 
the  TACIP  program  is  being  phased  out.  The  needs  which  TACIP  was  created  to 
serve  will  remain  valid,  however,  and  the  C^I  Directorate  of  CACDA  will  con¬ 
tinue  to  perform  the  functions  of  TACIP  listed  above. 
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2.4.  The  Army  Command  and  Control  System 


The  Army  Command  and  Control  System  (ACCS)  program,  the  joint  responsibil¬ 
ity  of  the  TRADOC  and  AMC  commanders,  encompasses  the  entire  Army.  The  ACCS 
architecture,  as  described  in  the  1985  Army  Command  and  Control  Master  Plan 
(AC2MP),  can  best  be  described  as  an  integrated  system  of  systems  which,  as  it 
evolves,  will  provide  the  capabilities  required  to  assist  commanders  and  staffs 
at  all  echelons  in  the  command  of  forces  and  control  of  resources.  In  its 
broadest  context,  the  ACCS  is  time  independent  and  supports  all  Army  functions 
in  peacetime,  in  the  transition  to  war,  and  in  wartime.  It  contains  four  in¬ 
terrelated  components: 

1 .  The  Army  portion  of  the  World-Wide  Military  Command  and  Control  System 
(WWMCCS) .  WWMCCS  was  established  by  the  president  to  provide  for  command  and 
control  of  all  U.S.  forces  and  integrates  the  headquarters  of  each  military 
department,  the  Joint  Chiefs  of  Staff,  unified  and  specified  commands,  joint 
task  forces,  service  component  commands,  and  selected  MACOMs. 

2.  The  Department  of  the  Army  Command  and  Control  System  (DACCS).  The 
DACCS  extends  communications  from  Headquarters,  Department  of  the  Army,  to  the 
headquarters  of  MACOMs  in  the  CONUS  and  Army  component  commands  of  joint  com¬ 
mands  located  overseas. 

3.  The  command  and  control  systems  of  Major  Army  Commands.  Within  the 
CONUS,  MACOMs  employ  Internal  command  and  control  systems  to  accomplish  as¬ 
signed  missions.  These  systems  are  designed  to  meet  the  needs  of  the  MACOM, 
and  generally  each  system  is  unique. 

A.  The  Command,  Control,  and  Subordinate  Systems  (CCS2).  CCS2  is  the  tac¬ 
tical  portion  of  the  Army  Command  and  Control  System  encompassing  elements  at 
corps  and  below. 

Figure  2-1  depicts  the  top-level  functional  framework  for  the  ACCS  archi¬ 
tecture  and  places  CCS2  in  context.  Each  of  the  four  time  phased  readiness 
functions  of  training,  mobilization/deployment,  sustainment,  and  employment  are 
shown  as  they  transcend  the  geographic  zones  from  left  to  right.  Information 
linkage  is  shown  by  connecting  lines.  CCS2  represents  the  Army's  battlefield 
architecture.  It  is  a  wartime  system  and  does  not  include  administration  or 
support  associated  with  peacetime  functions.  It  is  further  subdivided  into 
five  functional  segments  or  subsystems  whloh  exercise  control  of  resources 
allocated  to  the  segment.  The  five  functional  segments  are:  (1)  maneuver 
oontrol,  (2)  fire  support,  (3)  intelligence  and  electronic  warfare,  (4)  air 
defense  artillery,  and  (5)  combat  service  support.  Each  functional  segment  is 
served  by  a  oontrol  system  establishing  vertical  links  between  the  elements  of 
that  segment  located  at  echelons  from  corps  down  to  brigade  level.  (Maneuver 
control  and  CSS  extend  to  battalion  level.)  The  five  control  systems  are:  (1) 
Maneuver  Control  System  (MCS),  (2)  Advanced  Field  Artillery  Tactical  Data  Sys¬ 
tem  ( AFATDS) ,  (3)  AH  Source  Analysis  System  (ASAS),  (4)  Air  Defense  Command 
and  Control  System  (ADCCS),  and  (5)  the  Combat  Service  Support  Control  System 
(CSSCS).  MCS  is  the  most  advanced  in  development  of  the  five  systems  and  will 
be  the  first  fielded. 
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Figure  2-1.  ACCS  TOP  LEVEL  FUNCTIONAL  FRAMEWORK 
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Figure  2-2  illustrates  the  CCS2  concept  at  a  single  echelon.  The  five 
pointed  star  portrays  the  horizontal  integration  of  information  and  decisions 
within  a  force  level.  The  commander  and  his  staff  command  and  control  the 
force  through  the  maneuver  functional  node.  Information  is  exchanged  with  the 
subordinate  maneuver  commands  as  well  as  with  the  remaining  four  functional 
area  control  representatives,  e.g.,  DIVARTY  commander  for  FS  and  DISCOM  com¬ 
mander  for  CSS  (represented  by  the  unshaded  boxes).  The  shaded  boxes  represent 
the  subordinate  systems  to  a  specific  control  system.  The  subordinate  systems 
process  technical  and  staff  information  required  for  the  command  and  control  of 
the  functional  area. 

The  Army  is  evaluating  the  concept  that  the  ACCS  can  use  a  common  set  of 
hardware  based  on  three  basic  classes  of  equipment:  (1)  The  transportable,  or 
large  size,  which  is  vehicle  mounted,  (2)  the  portable,  or  mid-size,  which 
weighs  approximately  90  lbs  and  can  be  lifted  by  two  men,  and  (3)  the  hand  held 
or  small  size,  which  weighs  a  maximum  of  11  lbs  and  is  the  size  of  a  briefcase. 
Each  of  the  three  classes  of  equipment  will  be  procured  in  three  hardness  re¬ 
quirements:  commercial,  ruggedized  or  full  mil  spec.  The  government  will 
solicit  industry  to  provide  hardware  and  logistical  support  to  fill  all  nine 
categories  of  size  and  hardness.  Depending  on  criticality  of  mission  and  loca¬ 
tion  on  the  battlefield,  units  will  receive  equipment  with  appropriate  degree 
of  hardness.  Three  hardware  components  have  already  been  developed: 

1.  Tactical  Computer  System  (TCS) 

2.  Tactical  Computer  Terminal  (TCT) 

3.  Tactical  Computer  Processor  (TCP) 

Each  of  these  systems  are  multi-purpose  devices  capable  of  performing  nu¬ 
merous  command  and  control  functions.  The  TCS,  and  TCT,  are  militarized,  gen¬ 
eral  purpose  computers.  They  provide  information  processing  capabilities  and 
are  highly  reliable  and  survlvable  devices.  They  are  designed  to  provide  con¬ 
tinuous  C2  support  for  tactical  operations  regardless  of  the  tactical  or  envi¬ 
ronmental  conditions.  The  TCP  is  a  non-developmental  item  (NDI)  device  and,  as 
such,  is  less  survlvable  than  the  mil  spec  equipment  but  provides  robustness 
and  greater  data  processing  capabilities.  The  TCP  also  provides  the  color 
graphic  capability  which  is  not  currently  available  on  the  militarized  equip¬ 
ment.  Technical  specifications  of  the  TCS,  TCT,  and  the  TCP  are  shown  in  Table 
2-1. 
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Figure  2.2.  COMMAND,  CONTROL  AND  SUDORDINATF  SYSTEMS 


Table  2-1. 


MCS  Hardware  Device  Description 


TCS  TCT  TCP 


Processor 

1666BV3  16  BIT 

M68000  16  BIT 

M68000  16  BIT 

RAM 

1  MB 

1  MB 

1  MR 

Secondary  Storage 

8  MB 

600  KB 

55  MB 

Communication  Channels 

12 

2 

2 

Printer 

Thermal 

Thermal 

Thermal 

Type  Screen 

Plasma 

Plasma 

CRT/Touch  Sensitive 

Screen  Size 

8  1/2"  x  8  1/2" 

8  1/2"  x  8  1/2" 

8  1/2"  x  8  1/2" 

Weight 

972  lb 

519  lb 

844  lb 

Cubit  Feet 

41 

22 

44.5 

Operating  Temperature 

-40  -  130°F 

-40  -  130°F 

32-1 10°F 

Power 

110-240  AC 

110-240  AC 

110-240  AC 

28  VDC 

28  VDC 

238  VDC 

Power  Consumption 

295  watts 

295  watts 

600  watts 

2.5.  The  Maneuver  Control  System 

MCS  Is  a  corps-wide  system  which  will  provide  automated  support  to  the 
commander  and  his  G-3/S-3  staff.  It  is  employed  at  both  heavy  and  light  units, 
at  echelons  from  battalion  to  corps.  The  maneuver  functional  area  includes 
Armor,  Infantry,  Aviation,  Signal,  Engineer,  Military  Police,  NBC,  and  Echelons 
above  corps  units.  MCS  will  have  automated  interfaces  with  the  control  systems 
of  the  Fire  Support,  Air  Defense,  Intelligence  and  Electronic  Warfare,  and 
Combat  Service  Support  functional  areas.  The  MCS  will  serve  as  a  model  for 
these  four  remaining  control  systems  and  the  MCS  program  will  provide  an  in¬ 
terim  automation  capability  by  distributing  automated  devices  to  these  func¬ 
tional  segments  at  corps  and  division  level.  As  the  functional  areas  begin  to 
field  their  objective  systems,  they  will  replace  the  interim  devices. 

Central  to  MCS  operation  is  its  data  base  management  system.  Messages  are 
entered  by  selecting  the  appropriate  Army  Command  and  Control  System/Message 
Text  Format  (ACCS/MTF)  and  filling  in  the  requested  information.  By  means  of 
prompts,  the  MCS  assists  the  operator  in  composing  the  message.  Upon  receipt 
of  a  message,  the  MCS  Data  Base  Management  System  examines  the  messages,  iden¬ 
tifies  the  important  items  of  information  and  enters  these  items  into  the  data 
base  of  the  MCS  device.  Queries  to  the  data  base  may  be  operator  initiated  or 
may  result  automatically  as  a  result  of  a  previously  entered  Standing  Request 
for  Information. 

Although  the  Main  CP  is  the  primary  focal  point  of  command  and  control  at 
each  echelon  of  force,  the  TAC  or  Rear  CP  must  be  capable  of  assuming  the  prin¬ 
cipal  command  and  control  functions  for  the  force  in  the  event  of  the  failure 
or  destruction  of  the  Main  CP.  The  MCS  provides  this  capability  to  each  level 
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of  force  by  replicating  the  contents  of  the  G-3/S-3  operations  database  at 
three  locations  for  the  corps  and  division  echelon  (i.e.,  Main  CP,  TAG  CP,  and 
Rear  CP)  and  two  locations  for  the  brigade  and  battalion  echelon.  In  the  event 
the  commander  is  unable  to  command  from  any  of  the  three  principal  force  level 
CPs,  he  can  still  exercise  command  and  control  of  his  force  from  any  of  his 
major  subordinate  commands  (MSC).  Each  force  level  MSC  maintains  its  parent 
units  operational  graphics,  battle  resource  status,  and  intelligence  situation. 
Information  availability  at  a  MSC  can  be  expanded  by  reconstituting  the  force 
level  MCS  database  at  the  MSC  or  by  querying  other  C2  automated  systems  for 
specific  items  of  information  needed. 

In  addition  to  data  base  management,  the  data  processing  capabilities  of 
the  MCS  Include  the  creation  of  spreadsheets  and  graphics.  Information  is 
presented  in  the  form  of  color  decision  graphics  of  three  categories:  opera¬ 
tions,  battle  resources,  and  intelligence.  Figure  2-3,  2-4,  and  2-5  furnish 
examples  of  the  three  categories  of  display.  The  actual  displays  use  the  col¬ 
ors  red,  green,  and  amber  to  highlight  the  information  and  may  be  presented  at 
various  levels  of  detail.  Map  graphics  may  also  be  displayed  at  various  scales 
1:25,000  to  1:250,000  (standard  military  map  colors)  and  the  viewing  area  may 
be  focused  to  a  particular  area  of  interest.  The  graphic  displays  are  fully 
interactive  with  the  data  base;  tactical  information  from  the  data  base  may  be 
overlaid  on  the  map  graphic.  The  major  changes  to  MCS  design  resulting  from 
the  merger  with  DCCS  were  the  addition  of  integrated  color  graphics  and  color 
decision  displays,  force  level  staff  integration,  key  information  requirements 
for  the  commander,  and  the  distribution  of  terminals  at  battalion  level. 

The  development  and  maintenance  of  system  software  for  MCS,  as  well  as  the 
four  other  control  systems  of  CCS2,  is  the  responsi bl 11 ty  of  the  CECOM  Software 
Development  Support  Center  (SDSC)  located  at  Fort  Leavenworth,  Kansas.  Each  MCS 
user  will  receive  three  identical  sets  of  removable  storage  media,  one  for 
wartime  use,  one  for  training  use,  and  an  additional  backup  set.  SDSC,  CECOM 
la  also  responsible  for  updating  the  software  yearly,  conducting  verification 
tests,  and  distributing  the  updated  software  to  MCS  users.  The  software  ver¬ 
sions  will  be  released  annually,  in  July.  Each  version  provides  additional 
capabilities  and  functions  to  the  MCS  user  based  on  user  recommendations,  re¬ 
quirements,  and  reactions  to  previous  MCS  software  versions.  The  following 
chapters  of  this  manual  provide  practical  advice  to  aid  users  in  the  important 
task  of  developing  ideas,  analyzing  concepts,  and  defining  requirements  in  a 
manner  which  will  be  of  most  value  to  the  software  developers. 

Automation  of  tactical  operations  has  made  a  slow  but  steady  progress  since 
the  end  of  World  War  II  and  will  show  accelerated  development  in  the  late  1980s 
and  1990s.  The  potential  is  so  great,  it  seems  inevitable  that  applications  of 
automation  will  enable  the  U.S.  Army  to  achieve  modes  of  operation  which  can 
scarcely  be  envisioned  today.  MCS,  the  other  control  systems  of  CCS2,  and 
their  evolutionary  successors  will  soon  provide  what  LTG  R.W.  RisCassi  (Com¬ 
mander  of  the  Combined  Arms  Center  and  former  Commander  of  9th  Infantry  Divi¬ 
sion),  has  termed  an  "electronic  mountain"  from  which  the  commander  can  see  the 
battlefield  and  control  his  forces  with  great  accuracy  and  speed  and  thus  can 
truly  turn  within  the  enemy  commander's  decision  cycle. 
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Figure  2-3.  MCS  Display:  Unit  Battle  Resources. 


Figure  2-4.  MCS  Display:  Individual  Avenue  of  Approach. 


Figure  2-5.  MCS  Display:  Area  of  Operations. 


CHAPTER  3:  BASIC  GUIDELINES  FOR  ORGANIZING  THE  EFFORT 


The  following  suggestions  are  based  on  observations  of  and  discussions  with 
units  in  the  field  which  have  attempted  to  incorporate  automation  in  their 
operations.  They  Include  the  concepts  that  seem  to  work  best  in  assigning  the 
required  personnel  and  organizing  the  effort.  The  suggested  outline  will  have 
to  be  modified  depending  upon  the  scope  of  the  project.  If  you  are  submitting 
requirements  to  the  CCS2  or  adapting  software  which  has  been  developed  by  an¬ 
other  unit  you  will  need  considerably  less  technical  support  than  if  you  are 
developing  an  entire  application. 

As  in  organizing  any  such  wide-ranging  effort,  the  key  factor  is  getting 
the  right  people  assigned,  people  with  the  required  skills,  and  time  to  devote 
to  it.  Basically,  three  different  groups  of  personnel  are  of  concern  for  this 
effort: 


•  The  Users:  These  must  include: 

-  The  commander  and  senior  staff  who  are  the  ultimate  users  of  the 
tactical  information  system  and  will  be  the  principal  beneficiaries  of  improve¬ 
ments  in  staff  operations. 

-  Other  members  of  the  staff  whose  activities  will  be  affected  or 
changed  by  computer  support. 

•  The  Technicians:  These  are  the  experts  in  both  hardware  and  software. 
They  know,  in  a  technical  sense,  both  the  capabilities  and  limitations  of  auto¬ 
mation. 


•  The  Change-Agents:  These  are  those  few  rare  individuals  who  can  speak 
both  "militarese"  and  "computerese"  and  thereby  facilitate  communication  be¬ 
tween  the  first  two  above. 

Of  the  three  classes  of  personnel  cited,  the  technicians  are  the  most 
obvious  shortfall  in  your  current  TOE.  There  are  three  possible  sources  for 
such  hardware  and  software  expertise: 

•  The  Force  Hoderni zati on/Foroe  Development  (FM/FD)  personnel  assigned  to 
your  unit. 

•  The  Automation  Management  Office  or  Officer(s)  (AMO)  assigned  to  your 
unit. 


•  Contractor  support. 

The  first  two  groups  named  above  operate  differently  in  different  commands, 
so  you  will  have  to  adjust  your  requests  to  the  local  ground  rules.  FM/FD 
personnel  have  been  trained  in  system  analysis  and  may  or  may  not  have  exten¬ 
sive  ADP  experience  in  their  backgrounds.  AMO  personnel,  on  the  other  hand. 
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have  definitely  had  extensive  training  and  experience  in  automation,  although 
they  have  been  primarily  concerned  with  some  of  the  large,  centralized  data 
processing  systems. 

The  change-agents  are  the  key  ingredient,  forming  the  bridge  between  the 
other  two  groups.  The  successful  implementation  of  computer  support  to  the 
system  is  a  classic  example  of  the  joint  effort  of  two  completely  different 
kinds  of  expertise.  Only  military  experts  understand  the  true  nature  of  what 
the  system  is  trying  to  accomplish  and  its  operating  environment.  The  techni¬ 
cal  expert  in  hardware  and  software,  on  the  other  hand,  is  completely  familiar 
with  the  capabilities  and  limitations  of  automation  but  has  difficulty  express¬ 
ing  these  in  the  operational  terms  familiar  to  the  military  expert.  Getting 
these  two  groups  to  communicate  is  the  real  key  to  producing  a  useful  system 
design  which  is  acceptable  to  the  user.  This  process  can  be  expedited  by  mak¬ 
ing  available  the  few  Individuals  who  have  even  limited  expertise  on  both  sides 
of  the  fence.  Frequently  these  will  be  officers  who,  even  though  they  are 
relatively  junior  and  have  limited  staff  experience,  have  had  enough  exposure 
to  automation  so  that  they  can  talk  to  the  technicians.  Such  an  Individual  can 
act  as  an  expediter  or  catalyst  to  get  the  dialogue  between  military  and  tech¬ 
nical  experts  started  and,  in  effect,  to  translate  from  one  set  of  expertise 
into  the  other.  Top-down  or  oommand  emphasis  is  the  key  to  making  this  rare 
resource  available  even  on  an  ad  hoc  basis. 

Figure  3-1  shows  one  suggested  way  in  which  personnel  from  the  above  groups 
can  be  organized.  It  shows  a  steering  committee  and  a  project  officer  with 
direct  access  to  the  office  of  the  CG/CS.  The  steering  committee  is  dhaired  by 
the  CG/CS;  members  include  the  coordinating  staff  chiefs  and  the  project  offi¬ 
cer.  The  latter  can  be  accompanied  by  the  senior  technical  person.  Under  the 
project  officer  is  a  user  group  with  representatives  from  the  affected  staff 
sections  and  one  or  more  senior  technicians  —  which  ones  to  be  determined  by 
the  application  being  defined.  Also  under  the  project  officer  is  a  Technical 
Group  including  the  technicians  and  representatives  from  the  Immediately  af¬ 
fected  staff  sections  —  which  ones  to  be  determined  again  by  the  application 
under  development.  The  project  officer  must,  for  such  an  organization  to  be 
effective,  be  of  the  change-agent  type.  The  more  of  these  that  can  be  identi¬ 
fied  and  assigned  throughout  this  organization,  the  more  rapidly  the  users 
and  technicians  will  be  able  to  function  together  effectively.  It  is  most 
important  to  impress  them  with  the  idea  that  their  mission  is  to  make  data 
processing  technology  useful  to  the  user  and  to  translate  military  require¬ 
ments  into  terms  the  technicians  can  understand.  Their  function  is  not  to 
become  system  salesmen. 

Successful  introduction  and  implementation  of  automation  support  for  the  C2 
system  is  based  on  the  application  of  the  following  operational  principles: 

•  You  must  first  develop  a  system  concept.  Just  as  a  successful  OPLAN 
must  be  based  on  a  carefully  selected,  clearly  enunciated  concept  of  opera¬ 
tions,  so  also  must  the  initial  Implementation  (and  subsequent  iterations)  of 
automated  support  be  tied  to  a  carefully  developed  concept  of  "information 
operations"  when  the  C2  system  is  supported  with  automation.  The  system  con¬ 
cept  must  satisfy  the  requirement  in  the  same  way  that  the  concept  of  opera¬ 
tions  must  provide  for  the  accomplishment  of  the  mission. 
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Figure  3-1.  A  SUGGESTED  OVERALL  ORGANIZATION 
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•  Commander  and  senior  ataff  must  be  personally  involved.  No  change  to 
the  C2  system  —  and  the  introduction  of  automation  will  Introduce  some  pro¬ 
found  changes  —  can  succeed  without  the  personal  Involvement  of  the  commander 
and  senior  affected  staff  officers.  After  all,  the  C2  system  exists  solely  for 
the  purpose  of  facilitating  the  making  of  decisions  by  the  commander  and  senior 
staff;  it  is  their  system;  it  must  help  them  solve  their  problems  in  their 
unique  mode  of  decision  making.  Unless  they  have  helped  develop  the  concept 
and  have  interest  in  its  implementation,  the  concept  will  fail. 

•  The  effort  must  be  coordinated.  A  great  deal  of  work  might  be  saved  by 
first  investigating  what  other  units  have  accomplished.  The  1985  C2MUG  Soft¬ 
ware  Catalog,  published  by  the  Communications-Electronics  Command  (CECOM)  at 
Fort  Leavenworth,  Kansas  lists  110  software  applications  which  were  developed 
by  the  military  and  are  available  without  charge.  Automation  Management  Of¬ 
fices,  in  units  similar  to  yours,  will  also  be  able  to  tell  you  what  has  been 
done  by  that  unit.  Even  if  you  are  breaking  new  ground,  be  sure  to  coordinate 
your  effort  through  C^I  Directorate,  Combined  Arms  Combat  Developments  Activity 
at  Fort  Leavenworth,  to  make  sure  your  initiative  is  aligned  with  ACCS  archi¬ 
tecture.  CACDA  also  can  provide  suppc-t  in  defining  C 2  system  requirements, 
Information  on  the  initiatives  of  Army  units  worldwide,  and  assistance  in  con¬ 
ducting  field  evaluations. 

•  Automation  must  be  Integrated  into  total  system  operation.  There  is 
much  more  to  the  introduction  of  automated  support  than  merely  making  data 
processing  gear  available  to  the  staff.  Even  though  the  initial  concept  may  be 
limited  to  providing  support  for  only  one  or  two  applications,  the  impact  on 
the  remainder  of  the  system  of  providing  that  limited  support  must  be  assessed 
if  the  potential  benefit  is  to  be  in  any  way  exploited. 

•  Implementation  must  be  phased  in  gradually.  Even  though  any  degree  of 

automation  requires  a  total  system  evaluation,  the  concept  implementation  must 
be  carefully  phased  so  that  the  effort  does  not  exceed  man,  machine,  or  system 

capabilities  at  any  stage.  It  is  far  better  to  have  potential  customers  wait¬ 

ing  for  an  application  than  to  promise  something  you  can't  deliver. 

•  System  development  must  be  an  evolutionary  process.  Phased  implementa¬ 

tion,  in  turn,  requires  evolutionary  development.  Establish  initial  goals, 
develop  the  needed  support,  try  it  out,  improve  it  and  then  go  on  to  new  goals. 

It  should  be  noted  that  the  development  of  a  C2  system  will  never  be  finished 

or  completed. 

In  addition  to  the  guidelines  enunciated  above,  one  needs  to  follow  a  logi¬ 
cal  sequence  of  stages  and  tasks  in  implementing  the  effort.  Such  a  sequence 
is  provided  by  Figure  3-2  which  is  sort  of  a  roadmap.  It  lists  five  stages 
which  should  be  followed  for  each  Incremental  application  of  automation  to  the 
C2  system.  Indicates  who  has  the  lead  for  each  stage,  and  shows  the  tasks 
required. 

Figure  3-3  shows  the  suggested  involvement  by  the  Commander,  Chief  of  Staff 
and  Senior  Staff  in  the  task  sequence  portrayed  in  Figure  3-2.  It  indicates 
the  nature  of  each  contact  and  its  purpose.  The  contacts  with  senior  users 
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Figure  3-2.  ROAD  MAP  FOR  ORGANIZING  EFFORT 
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Figure  3-3.  SENIOR  USER  INVOLVEMENT  DURING  DEVELOPMENT 


indicated  in  the  figure  are  the  absolute  minimum;  other  progress  briefings  are 
clearly  indicated  for  some  of  the  longer  stages  such  as  concept  development  and 
software/system  development. 

The  goals,  i.e.,  the  output  products,  selected  in  concept  development  for 
improvement  through  computer  support  must  be  of  major  concern  to  the  commander 
and  principal  staff.  Since  the  C2  system  exists  to  support  their  decision 
making,  they  are  the  principal  users  and,  hence,  very  properly  make  the  final 
decisions  as  to  how  that  system  will  function  and  be  organized.  It  is,  there¬ 
fore,  of  the  utmost  importance  that  they  select  the  initial  package  of  staff 
outputs  to  be  assisted  through  automation.  Furthermore,  it  is  to  the  commander 
and  senior  staff  that  the  improvements  achieved  must  be  demonstrated.  There¬ 
fore,  they  must  also  be  involved  in  the  selection  of  measures  used  to  demon¬ 
strate  that  improvement.  It  is  not  sufficient  to  have  a  top-down  approach  to 
system  design;  there  must  also  be  top-down  involvement  in  its  implementation  or 
the  effort  will  surely  fail. 

The  initial  briefing  is  certainly  the  most  important  since  it  will  set  the 
stage  for  the  entire  development.  It  should  take  place  as  soon  as  possible 
after  receipt  of  the  mission.  The  project  officer(s)  should  do  enough  prelimi¬ 
nary  work  so  that  they  can  discuss  the  nature  of  the  effort  required,  the  major 
capabilities  and  limitations  of  automation,  and  some  candidate  applications  and 
goals.  They  should  indicate  the  nature  of  and  estimate  the  size  of  the  re¬ 
sources  required  and  outline  the  proposed  organization  of  the  effort.  Almost 
as  Important  as  the  initial  briefing  is  the  "hands  on"  experience  during  the 
initial  operator  training  and  the  later  demonstrations  and  trials.  If  the  ini¬ 
tial  application  to  be  Implemented  is  to  demonstrate  Improvements  achieved 
through  automation,  several  of  this  senior  group  (Commander,  Chief  of  Staff, 
and  senior  staff  officers)  must  be  involved  at  the  terminals.  There  is  no 
better  or  faster  way  to  gain  an  appreciation  of  the  potential  for  Improvement. 
The  remainder  of  the  briefings  are  decision  briefings  at  key  points  in  the  de¬ 
velopment  cycle. 
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CHAPTER  **:  FLOW  CHARTS  OF  INFORMATION  PROCESSING  SYSTEMS 

Chapter  5  will  present  a  method  of  concept  development,  beginning  with  the 
search  for  ideas  and  tracing,  step  by  step,  the  refining  of  the  ideas  into 
analyzed  concepts  for  automation.  Before  presenting  that  method,  this  chapter 
discusses  two  tools  which  will  be  helpful  in  that  process:  flow  charts  of 
information  processing  systems,  and  a  method  of  estimating  the  potential  bene¬ 
fits  of  automation. 

Information  processing  systems,  such  as  command  and  control  systems,  con¬ 
sist  of  three  major  components:  (1)  databases,  in  which  information  is 
stored,  (2)  functions,  which  operate  on  information,  changing  or  reorganizing 
it,  and  (3)  interfaces,  which  are  connections  or  routes  between  functions  and 
databases  along  which  information  is  transferred.  Flow  charts  illustrate  the 
system,  using  boxes  to  represent  functions  and  databases  and  arrows  to  repre¬ 
sent  the  interfaces  between  them.  You  will  need  to  make  flow  charts  to  show 
how  the  system  you  hope  to  improve  operates  now,  and  how  it  will  operate  after 
automation. 


If  the  application  Involves  some  decision  making  aspects,  and  that  will 
probably  be  the  case,  a  useful  start  on  the  flow  charts  can  be  made  by  dividing 
the  process  into  five  components: 


1.  Input:  information  is  gathered 

2.  Pre-decision:  information  is  reorganized  for  the  decision 

3.  Decision 

*».  Post-decision:  information  is  organized  for  output 


5.  Output:  decision  is  implemented 

To  illustrate,  we  will  consider  the  operation  of  the  C2  system  in  the  TOC, 
although  your  application  will  undoubtedly  be  more  restricted  in  scope. 


For  our  purposes,  the  C*  system  is  defined  to  include  sll  commanders,  their 
staffs,  and  all  communications,  sensors,  personnel,  equipment,  facilities,  and 
procedures  used  in  planning,  directing,  coordinating,  and  controlling  the  as¬ 
signed  forces.  Figure  *1-1  is  a  schematic  of  the  C2  system  at  a  single  echelon 
of  command.  The  Tactical  Operations  Center  (TOC)  is  shown  as  an  information 
processing  node,  in  which  information  is  received  as  inputs,  processed,  and 
generated  as  outputs.  There  are  a  hierarchy  of  such  loops  in  the  military 
structure.  At  each  echelon  the  system  tries  to  achieve  the  set  of  goals  pre¬ 
scribed  in  its  mission. 


The  major  functions  which  c?  >  distinguished  within  the  TOC  are  illus¬ 
trated  in  Figure  *1-2.  Incoming  .  ssages  are  transmitted  by  the  input  function 
to  a  raw  data  base  (message  file)  and  the  pre-decision  function.  The  input 
function  is  responsible  for  receiving  messages,  verifying  the  accuracy  of  the 
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Figure  4-1.  A  SCHEMATIC  OF  THE  C2  SYSTEM 
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transmission,  and  tagging  the  incoming  messages  with  an  identifier.  The  input 
function  further  throughputs  the  messages  to  a  raw  data  base  (message  file, 
staff  journal)  and  to  the  pre-decision  function. 

The  pre-decision  function  extracts  data  from  the  incoming  messages  and 
enters  it  in  structured  form  into  the  processed  data  base,  thereby  creating  and 
continually  updating  the  useable  data  base.  In  the  manual  (non-automated) 
mode,  section  files  and  displays  are  instances  of  the  processed  data  base.  The 
pre-decision  function  sorts  the  messages  according  to  some  predetermined  clas¬ 
sification  scheme.  For  example,  unit  locations  are  extracted  from  SITREPs. 
Sorted  information  is  then  associated  with  other  Information  in  the  same  or  a 
related  class,  for  example,  by  answering  the  question  "Is  the  1st  Battalion  of 
the  32nd  Tank  Regiment  part  of  the  20th  Guards  Tank  Division?".  The  pre-deci¬ 
sion  function  also  organizes  and  aggregates  by  combining  the  associated  infor¬ 
mation  and  arraying/displaying  it  in  a  manner  that  facilitates  the  decision 
processes,  for  example,  updating  the  Order  of  Battle. 

The  decision  function  extracts  information  in  a  structured  form  from  the 
data  base,  manipulates  and  augments  the  information,  adds  new  structures,  makes 
assumptions  to  cover  the  gaps,  reinterprets  the  results,  and  selects  the  ac¬ 
tions  to  be  implemented.  The  activities  of  the  decision  process  illustrated  in 
Figure  4-2  begin  with  interpretation  and  validation  of  the  information,  whereby 
cause-and-effect  relationships  are  hypothesized  and  the  probability  of  these 
relationships  representing  ground  truth  is  assessed.  (How  can  the  2/31  Battal¬ 
ion  continue  to  advance  at  over  5km/hr  against  two  regiments  when  it  has  sus¬ 
tained  a  reported  60  percent  casualties?)  Next  follows  a  process  of  evaluation 
and  coordination  to  determine  whether  the  perceived  situation  warrants  consid¬ 
eration  of  taking  further  action  or  of  sharing  the  perception  with  another 
command  control  group.  (Does  the  gap  apparently  opening  up  on  our  right  flank 
warrant  issuing  a  frag  order,  or  notifying  the  adjacent  unit,  or  both?)  Projec¬ 
tions  and  extrapolations  are  made  to  estimate  probable  future  situations  based 
on  current  or  predicted  trends.  (Where  and  when  must  I  lay  on  the  next  ammuni¬ 
tion  resupply  operation  if  present  expenditure  and  movement  rates  continue?) 
Alternatives  are  generated  concerning  friendly  and  enemy  courses  of  action, 
possible  enemy  missions  are  inferred  and  enemy  capabilities  are  determined,  and 
finally  a  decision  is  reached  concerning  which  of  the  alternatives  considered 
is  most  likely  to  yield  the  greatest  success  in  accomplishing  the  mission. 

The  post-decision  function  converts  decisions  into  messages  and  further 
updates  .the  data  base.  Relevant  information  is  reaggregated  into  preparation 
of  an  output  message.  Segments  of  the  message  are  arranged  in  the  selected 
format,  and  distribution  is  determined.  The  output  function  tags,  transmits, 
and  verifies  the  message,  and  transfers  it  to  the  message  file  and  the  informa¬ 
tion  stream. 

Lest  one  fall  into  the  trap  of  regarding  the  TOC  as  an  entirely  reactive 
entity,  one  must  recognize  the  arrows  shown  in  Figure  4-2  indicates  only  infor¬ 
mation  transfers  among  the  components  of  the  TOC.  They  neither  imply  that  th’s 
is  a  continuous  process  nor  that  every  input  produces  an  output,  nor  even  that 
all  outputs  can  be  traced  to  specific  inputs.  Just  as  individual  human  reac¬ 
tions  are  not  necessarily  always  triggered  by  external  stimuli,  group  outputs 
can  be  triggered  by  internal  stimuli  which  can  vary  in  complexity  from  periodic 
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reports  triggered  by  the  clock  to  actions  taken  as  a  result  of  profound  insight 
or  hypotheses  generated  long  after  the  arrival  of  the  latest  segment  of  raw 
data  that  has  been  considered. 

We  now  turn  to  the  question  of  estimating  the  potential  benefits  of  automa¬ 
tion.  We  will  use  the  model  of  TOC  information  processing  developed  above  to 
examine  the  question  of  the  relative  capability  of  man  and  the  machine.  Our 
intuition  tells  us  that  there  are  probably  a  number  of  processes  that  the 
machine  cannot  perform,  but  that  there  are  undoubtedly  some  which  it  can  per¬ 
form  much  better  than  man.  We  should  also  look  at  the  question  of  which  of 
these  processes  can  probably  be  performed  even  better  when  a  machine  supports  a 
human. 

Such  comparison  is  made  in  Table  4-1.  Listed  in  the  first  column  at  the 
left  are  the  information  processes  required  for  the  input,  pre-decision,  and 
decision  functions.  The  processes  required  for  the  post-decision  and  output 
functions  have  not  been  repeated  since  they  are  the  same  as  for  pre-decision 
and  inputs,  but  in  essentially  inverse  order.  The  second  column  lists  the 
dominant  characteristics  of  unaided  man  in  carrying  out  each  process  while  the 
third  column  lists  the  dominant  characteristics  of  the  automated  system  (ma¬ 
chine)  by  itself.  The  fourth  column  rates  the  potential  payoff  of  combining 
the  complementary  capabilities  of  both  man  and  machine,  i.e.,  of  providing 
computer  support  to  the  process. 

The  table  shows  that  complete  automation  of  the  input  and  output  processes 
offers  substantial  improvement  except  for  the  loss  of  the  "personal"  dimension 
so  clearly  a  basic  component  of  voice  communication.  The  latter  can,  of  course 
be  extremely  important  in  commander  to  commander  ex-changes.  Nevertheless,  the 
bulk  of  the  routine  traffic  could  be  handled  far  more  rapidly  and  expeditiously 
over  digital  links  —  provided  the  rest  of  the  system  could  handle  the  in¬ 
creased  information  load. 


We  note  that  the  next  three  processes,  which  are  invoked  for  pre-and  post¬ 
decision  processing,  are  distinctly  complementary  with  respect  to  man  vs  ma¬ 
chine  processing.  Only  man  can  provide  the  basis  for  sorting  and  the  needed 
sorting  keys,  the  association  algorithms,  and  the  formats  and  algorithms  needed 
for  aggregating  and  organizing.  On  the  other  hand,  man  is  very  slow  and  error 
prone  in  the  actual  conduct  of  these  processes,  while  the  machine  is  very  fast 
and  error  free  once  the  needed  sorting  keys,  algorithms,  and  formats  have  been 
provided.  Clearly,  these  are  processes  which  can  profit  from  joint  man-machine 
processing.  Fortunately,  too,  the  bulk  of  the  human  processing  required  can  be 
done  "off-line,"  that  is,  the  sorting  keys,  algorithms,  and  formats  can  be 
developed  in  advance  and  stored  in  the  computer.  The  bulk  of  this  pre-and 
post-decision  processing  can  therefore  be  shifted  to  the  machine  and  the  human 
processor  needs  to  assist  only  on  an  exception  basis.  Note,  however,  that  this 
also  shifts  some  of  the  burden  to  the  message  originator  who  must  now  format  or 
otherwise  provide  sorting  keys. 

When  we  examine  the  last  five,  the  decision  processes  themselves,  we  note 
that  not  only  are  man’s  creative  talents  required,  but  that  they  must  be  ap¬ 
plied  on-line  as  the  information  is  being  processed.  On  the  other  hand,  the 
computer  provides  the  ideal  medium  to  be  used  as  a  memory  and  mind  "extender" 
in  support  of  the  decision  maker.  Not  only  can  it  retrieve  any  data  item  in 


30 


Table  4-1.  COMPARISON  OF  MAN  AND  MACHINE  PROCESSING  CAPABILITIES 
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Table  4-1.  COMPARISON  OF  MAN  AND  MACHINE  PROCESSING  CAPABILITIES  (CONTD) 
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FINAL  DECISION  MORE  RAPIDLY.  LESS  ERROR 


memory,  but  It  can  display  it  in  whatever  manner  the  decision  maker  desires.  It 
can  operate  on  it  according  to  instructions  and  perform  calculations  without 
error,  and,  finally,  it  can  accept  new  items  created  by  the  decision  maker  as 
he  develops  and  tests  alternative  hypotheses.  At  a  still  higher  level  of  so¬ 
phistication  it  can  store  and  retrieve  both  enemy  and  friendly  doctrine  to 
still  further  assist  the  decision  maker.  When  stored  in  the  computer  with 
tests  and  rules  for  their  application,  these  become  artificial  intelligence, 
put  at  the  disposal  of  the  decision  maker.  The  result  of  this  combination 
provides  a  tremendous  amount  of  leverage  as  compared  to  the  decision  maker 
trying  to  operate  with  the  standard  "manual"  aids  consisting  of  manually  pre¬ 
pared  overlays  and  displays,  and  oral  briefings.  Interactive,  man-machine 
decision  making  not  only  leads  to  faster  but  also  to  better  decision  making  in 
that  all  the  available  and  pertinent  data  can  be  accessed  rapidly  and,  to¬ 
gether,  man  and  machine  can  better  cope  with  remaining  uncertainty. 

The  above  discussion  has  demonstrated  that  automation  can  help  achieve  such 
goals  as  reducing  time  lines,  providing  decision  aids,  and  managing  uncertainty 
of  the  database.  It  has,  however,  also  demonstrated  that  achieving  these  goals 
may  not  be  quite  as  simple  as  we  would  like  it  to  be.  Any  system  or  organiza¬ 
tion  composed  of  men  and  machines  really  has  four  distinct  variables  or  dimen¬ 
sions  which  can  be  manipulated  in  order  to  best  accomplish  the  assigned 
mission.  These  manipulable  variables  are: 

•  The  personnel  and  human  skills  available 

•  The  technological  "skills"  available 

•  The  breakdown  into  the  individual  tasks 

•  The  structure,  to  include  the  procedures  for  accomplishing  the  tasks 
required  by  the  mission 


These  four  variables  are  what  are  being  manipulated  in  any  endeavor  to 
improve  the  functioning  of  the  system.  Any  such  effort  involves  a  whole  series 
of  compromises  and  trade-offs  between  the  capabilities  and  limitations  of  the 
system  components.  Change  any  one  of  these  variables;  for  example,  technology, 
and  the  compromises  previously  worked  out  may  no  longer  be  valid.  In  general, 
a  change  in  any  one  requires  changes  in  all  the  others  in  order  to  exploit  the 
potential  improvement  to  the  utmost.  Think  of  the  profound  changes  in  person¬ 
nel  skills,  task  assignment,  and  structure  Introduced  into  military  forces 
between  1918  and  1939  by  the  introduction  of  the  tank  and  the  tactical  radio. 

An  example  with  respect  to  the  C 2  system  has  already  been  cited;  automation  of 
the  Input/output  processes  alone  will  almost  immediately  overload  the  rest  of 
the  decision  making  node.  One  must  never  overlook  that  the  tactical  C 2  system 
is  a  system  and  that  the  total  system  impact  on  any  change  must  be  considered. 
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CHAPTER  5: 


CONCEPT  DEVELOPMENT 


The  best  ideas  for  automation  of  tactical  or  garrison  operations  will  un¬ 
doubtedly  come  from  the  officers  in  the  field  units  who  are  the  experts  in 
command  and  control.  Whether  the  goal  is  to  submit  requirements  to  aid  in  the 
evolutionary  development  of  the  Army-wide  command  control,  and  subordinate 
systems  or  to  maximize  the  utility  of  computer  equipment  already  available  by 
developing  smaller  in-unit  applications,  the  initial  and  critical  step  is  the 
formulation  of  a  detailed  concept  of  automation.  Such  a  concept  must  include: 

•  A  clear  definition  of  what  is  to  be  accomplished  through  computer  support 
in  terms  of  measurable,  demonstrated  improvement  of  some  intermediate  or  final 
output  product  of  the  commander  and  staff. 

•  A  careful  analysis  of  the  processes  required  to  produce  the  particular 
staff  output  product  selected  above. 

•  Careful  selection  of  which  of  the  above  processes  are  to  be  assigned 
to  automation. 

•  A  detailed  set  of  procedures  for  performing  both  the  machine  and  human 
processing  required  to  produce  the  measurable  product.  This  will,  of  course, 
have  to  be  modified  as  the  development  proceeds  and,  most  certainly,  as  a  re¬ 
sult  of  the  initial  trials.  It  is  important  to  note  that  this  set  of  proce¬ 
dures  will  almost  certainly  be  different  from  the  procedures  used  in  manual 
processing. 

The  whole  notion  of  having  to  develop  a  formal  concept  of  "information 
operations"  is  somewhat  foreign  to  us;  after  all,  we  have  been  organizing  and 
training  staffs  for  years  without  prescribing  a  detailed  set  of  operational 
procedures  for  carrying  out  the  necessary  information  processes.  Such  detailed 
procedures  were  developed  as  we  needed  them.  A  formal  SOP  was  usually  prepared 
to  cover  such  special  requirements  as  displacement,  enemy  attack  on  the  CP, 
nuclear  release,  chemical  attack,  and  vitally  needed  reports,  but  the  routine 
processing  took  care  of  itself.  FM  101-5  describes  the  duties,  responsibi li- 
ties,  and  functions  of  commanders  and  staffs  and  describes  in  some  detail  what 
has  to  be  done.  Appropriate  TOEs  list  the  assets  authorized  to  perform  these 
tasks.  The  ARTEPS  provide  performance  standards  and,  hopefully,  personnel 
assigned  are  qualified  in  their  MOS. 

None  of  the  above  documents,  however,  provide  much  guidance  on  how  to  carry 
out  the  doctrinally  prescribed  tasks  other  than  a  few  formats  for  the  major 
staff  products  and  what  can  be  inferred  from  MOS  rpecified  skills.  Group  mem¬ 
bers,  Interacting  over  a  period  of  time,  will  develop  standard  work  patterns  in 
which  routine  and  precedent  play  a  relatively  large  part.  This  somewhat  casual 
approach  to  the  detailed  ordering  of  the  information  processing  is  understanda¬ 
ble  and  reasonably  successful  when  "machine"  support  is  limited  to  voice  and 
teletype  communication,  typewriters,  manual  displays  and  files,  and  possibly  a 
copy  machine  or  two.  In  such  a  manual  system,  information  processes  are  all 
performed  by  human  beings  which  are  among  the  most  highly  variable,  nonstandard 


parts  from  which  a  system  can  be  formed.  Furthermore,  humans  are  almost  infi¬ 
nitely  adaptable;  whenever  one  or  more  members  of  the  team  change,  the  rest 
adapt  to  the  skills,  limitations  and  preferences  of  the  replacements  —  espe¬ 
cially  of  the  senior  members.  As  a  result,  no  two  staffs  process  information 
in  exactly  the  same  way  nor  do  two  shifts  of  the  same  staff  operate  in  an  iden¬ 
tical  manner. 

The  advent  of  automated  support  changes  all  this.  Even  though  software  can 
be  made  somewhat  flexible  and  adaptive,  still,  to  the  degree  that  Information 
processing  is  performed  by  machine,  the  information  system  now  contains  "stan¬ 
dard"  parts  which  impose  a  degree  of  discipline  in  system  design  and  operation 
far  greater  than  was  required  when  it  was  populated  only  by  people.  This  does 
not  mean  that  automation  alone  can  drive  your  system  design.  Clearly  it  must 
respond  to  the  commander's  wishes  and  accommodate  the  real  world  situation. 
However,  without  a  detailed  concept  of  just  how  the  information  processing  is 
to  be  improved  through  computer  support,  the  effort  will  flounder;  very  little, 
if  any,  improvement  will  result,  and  many  resources  and  much  time  will  have 
been  wasted. 

5.1.  Identifying  Candidate  Applications 

The  key  to  getting  users  to  submit  original  and  useful  suggestions,  regard¬ 
less  of  what  means  are  used  to  elicit  them,  is  to  stimulate  the  user  by  pro¬ 
viding  some  well  thought  out  "strawmen."  People  are  always  more  willing  to 
comment  on  proposals  made  by  someone  else  than  they  are  to  initiate  original 
suggestions  —  and  in  the  process  of  commenting  they  will  frequently  be  stimu¬ 
lated  to  come  up  with  some  new  ideas.  The  group  solicited  for  suggestions  must 
include  the  commander  and  senior  staff  as  well  as  other  members  of  the  staff. 
Although  the  suggestions  from  the  commander  and  senior  staff  have,  ipso  facto, 
priority,  the  lower  level  participants  may  well  provide  valuable  insights  and 
plug  gaps  in  the  submissions  of  their  seniors.  One  possible  sequence  would  be 
to  use  a  questionnaire  to  elicit  comments  and  suggestions  on  a  set  of  applica¬ 
tions  you  have  provided  as  a  strawman.  Then,  after  you  have  listed  a  modified 
set  of  applications  based  on  the  questionnaire,  convene  a  brainstorming  session 
to  gain  a  consensus.  Anonymous  questionnaires  are  usually  preferable. 

Each  candidate  application  must  be  expressed  in  terms  of  clearly  identified 
products.  In  addition  to  Identifying  the  candidate  output  which  is  to  be  im¬ 
proved,  the  submission  must  specify  exactly  how  this  product  is  expressed  quan¬ 
titatively: 

•  Reduce  staff  preparation  time  for  this  _  to  less  than  30  minutes. 

•  Reduce  lag  time  between  input  message  and  _  to  less  than  5  minutes. 

•  Reduce  discrepancies  between  friendly  input  locations  and  displayed 
locations  to  less  than  IS. 

If  it  is  not  possible  to  express  the  improvement  quantitatively,  the  im¬ 
provement  goal  must  be  described  in  sufficient  detail  so  that  there  can  be  no 
doubt  when  the  desired  level  of  improvement  has  been  demonstrated. 
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5.2.  Applications  Analysis 


The  candidate  applications  must  now  be  analyzed  to  determine: 

•  Which  of  the  processes  required  for  each  application  can  be  supported  by 
automation. 

•  The  probable  contribution  of  each  toward  the  application  goal. 

•  The  probable  cost  in  time  and  dollars. 

The  suggested  way  to  Initiate  this  analysis  is  to  develop  a  flow  chart  of 
the  functions,  processes,  and  data  bases  required  to  produce  the  output(s) 
identified  in  the  specific  applications.  The  general  model  of  C2  group  proc¬ 
essing  steps  shown  at  Figure  4-2  provides  the  building  blocks  for  this  effort. 
Do  this  initially  to  show  how  these  outputs  are  produced  in  the  manual  mode. 
Include  all  of  the  processing  needed  all  the  way  back  to  the  data  stream,  both 
in  and  out. 

As  an  illustration  we  will  consider  an  example  which  is  similar  to  the  pro¬ 
ject  that  was  undertaken  by  the  ACCS  engineers  when  it  was  decided  to  incor¬ 
porate  force  level  Integration  into  MCS.  We  use  the  example  here  because  it  is 
generic  and  easily  understood.  It  is  unlikely  that  your  application  will  be  as 
broad  or  complex.  We  call  our  example  the  commander's  briefing  project.  The 
commander  has  expressed  the  desire  that  the  information  heretofore  provided  him 
at  the  morning  and  evening  briefing  be  made  available  to  him  through  a  computer 
terminal.  He  has  also  seized  on  the  possibility  that  by  this  means  he  can,  in 
effect,  receive  as  much  as  he  wants  of  the  briefing  at  any  time  without  waiting 
for  a  scheduled  briefing  and  the  information  provided  will  be  current,  l.e., 
represent  the  latest  staff  perceptions  and  recommendations,  whenever  he  re¬ 
quests  it. 

Each  staff  section  must  carry  out  all  of  the  processing  shown  in  Figure  4-2 
because  many  decisions  are  required  in  the  preparation  of  the  briefing:  Which 
information  should  be  presented?  What  additional  information  do  we  need?  What 
is  the  most  likely  interpretation  of  what  we  know?  What  are  the  most  appro¬ 
priate  courses  of  action?  What  recommendation  should  we  make?  In  making  these 
decisions,  each  staff  element  1s  determining  what  information  to  include  in  the 
briefing  and,  effectively,  creating  a  special  "briefing  data  base."  In  the 
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manual  mode  this  briefing  data  base  consists  of  the  briefing  maps,  overlays, 
and  charts  plus  the  information  conveyed  to  the  commander  from  the  memory  of 
the  briefing  officers.  Such  a  data  base  covers  the  entire  spectrum  of  the 
operations  of  the  command  as  a  whole,  but  will  be  less  detailed  than  the  proc¬ 
essed  (perceived)  data  bases  of  the  separate  staff  elements. 

Figure  5-1  illustrates  a  flow  chart  of  the  information  processing  required 
for  the  briefing  for  a  single  staff  element.  Notice  that  the  lower  two  thirds 
of  this  figure  is  identical  to  Figure  4-2  and  represents  the  processing  needed 
to  create  the  staff  section's  own  perceived  data  base  —  its  working  files  and 
displays.  In  addition,  Figure  5-1  has  added  another  output  from  the  staff 
section  decision  processes:  the  briefing  data  base.  This  is,  in  turn,  ac¬ 
cessed  by  the  commander's  decision  processes  and  further  updated  to  reflect  his 
decisions.  It  is  this  briefing  data  base  and  access  to  it  both  by  the  com¬ 
mander  and  staff  that  we  are  proposing  to  automate.  It  must  be  noted  that 
Figure  5-1  shows  the  processing  of  only  a  single  staff  element,  in  this  case, 
operations.  Each  of  the  other  coordinating  staff  sections  and  special  staff 
elements  must  go  through  the  same  series  of  processes.  Also  some  of  this  proc¬ 
essing  may  go  on  at  locations  other  than  the  TOC;  e.g.,  the  bulk  of  the  G-1  and 
G-4  sections  are  usually  at  Rear. 

Also  indicated  in  Figure  5-1  are  the  major  interfaces  or  data  exchanges 
that  need  to  take  place.  These  have  been  indicated  by  letters  A  through  G.  In 
most  cases  these  take  place  between  functions  and  data  bases  except  for  the 
interface  between  input/output  and  pre-,  post-decision  processing  which  do  not 
share  a  common  data  base. 

Your  flow  chart  will  have  to  be  modified  to  reflect  how  it  will  be  changed 
when  supported  by  the  proposed  automation.  This  will  be  an  iterative  procedure 
as  you  examine  several  different  candidate  processes  for  automation  and  recall 
that  an  automated  data  base  must  be  shown  separately  to  support  the  processes 
you  intend  to  automate.  The  major  change  from  the  manual  flow  chart  is  the 
identification  of  the  Interfaces  which  will  become  human-machine  terminals. 
Remember  that  you  must  ultimately  provide  for  every  data  element  needed  as 
input  into  the  automated  data  base  and  for  every  desired  output. 

5.3.  Sizing  and  Phasing 


\ 
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EXTERNAL  INFORMATION  STREAM 


Figure  5-1.  OPERATIONS  SECTION  PROCESSING 


For  the  larger  applications  such  as  the  Commander ' s  briefing  it  will  be 
clear  that  the  ultimate  goal  cannot  be  achieved  in  a  single  iteration.  Such  a 
single  massive  leap  into  automation  is  neither  practicable  nor  desirable.  Not 
only  would  it  exceed  currently  available  resources,  but,  even  more  importantly, 
it  would  require  a  period  of  time  to  plan,  design,  develop,  and  Implement  far 
longer  than  available.  If  improvement  of  the  operation  through  computer  sup¬ 
port  cannot  be  demonstrated  in  some  measurable  degree  during  the  current  tour 
of  duty  of  the  commander  and  senior  staff,  the  effort  will  most  assuredly  have 
to  start  all  over  from  scratch  at  some  future  time.  The  effort  to  provide 
computer  Support  must  be  phased.  This  means  not  so  much  curbing  the  appetite 
for  automation  as  breaking  it  into  chunks  of  manageable  size.  Each  application 
considered  should  lie  well  within  your  resources  both  in  terms  of  dollars  and 
available  technical  expertise  and  it  must  also  be  doable  and  demonstrable 
within  a  reasonably  short  period  of  time.  The  initial  application  should  also 
be  selected  on  the  basis  that  it  is  a  logical  first  step  toward  whatever  ulti¬ 
mate  goal  has  been  established  for  achievement  through  computer  support. 

Defining  and  phasing  the  successive  applications  which  will  lead  you  to  the 
ultimate  goal  that  has  been  established  requires  that  you  start  with  that  goal 
and  then  develop  an  appropriate  phasing  strategy  by  which  that  goal  can  be 
reached. 

There  are  some  basic  system  design  rules  which  should  be  observed  in  imple¬ 
menting  the  strategy: 

1 .  Each  successive  application  (not  .lust  the  first)  must  demonstrably  im¬ 
prove  the  performance  of  the  C2  system.  In  general,  this  means  that  the  appli- 
cation  must  be  tied  to  one  or  more  staff  products  and  specified  quantitative 
improvements  in  their  production. 

2.  In  planning  successive  applications,  each  should  exploit  the  capabil¬ 
ities  already  provided  by  its  predecessors.  It  cannot  be  repeated  too  often 
that  the  incremental  Introduction  of  automated  support  means  the  incremental 
transition  from  all-manually  created  to  automated  data  bases.  The  latter 
should,  of  course,  be  common  (accessible  by  anyone  who  needs  the  information) 
and  distributed  (for  survival).  Successive  applications  must  provide  for  an 
orderly  transition  from  one  to  the  other  with  minimal  duplication  of  labor  at 
each  intermediate  stage. 

3.  Use  commo  channels  only  for  the  transmission  of  dynamic  Information  — 
never  for  the  transmission  of  static  Information  which  should  be  stored 
locally.  Do  not  use  the  commo  system  to  transmit  complete  formats,  displays, 
or  charts.  Instead,  transmit  only  that  information  required  to  keep  the  data 
elements  in  the  data  base  current.  Ideally  the  user  snould  be  able  to  display 
the  data  he  needs  in  a  format  of  his  choice;  the  system  retrieves  the  updated 
data  elements  needed  to  complete  it.  As  an  obvious  example,  transmit  only  the 
data  on  the  overlay  —  not  the  entire  map  underneath  it. 

9.  A  top-down  approach  to  providing  automated  support,  i.e.,  beginning 
with  products  that  require  the  decision  processes,  then  the  pre-  and  post- 
decision  processes,  and  finally  the  input  and  output  processes,  will  lead  to  a 
more  efficient  system  design.  Numerous  visits  to  units  participating  in  the 
TACIP  program  have  emphasized  this  principle.  Defining  the  commander's  needs 
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first  makes  the  determination  of  what  -lata  are  needed,  where  to  get  them,  and 
how  to  sort,  correlate,  and  aggregate  them  for  presentation  a  relatively 
straightforward  task.  Starting  at  the  bottom  with  "electronic  •nail"  tends  to 
include  every  possibility  at  the  lower  levels  and  then  ignore  those  not  needed 
as  the  system  is  developed  upward. 

The  above  discussion  has  concentrated  on  the  question  of  defining  a  logical 
progression  of  applications  aimed  at  the  achievement  of  a  larger  goal.  For 
such  larger  applications  it  will  be  necessary  to  break  the  job  down  into  a 
series  of  steps  with  intermediate  goals  for  each.  This,  in  turn,  requires 
drafting  a  series  of  flow  charts,  one  for  each  product  that  is  to  be  produced 
with  automated  assistance.  Figures  5-2,  5-3.  and  5-4  have  been  designed  to 
assist  you  in  drafting  the  flow  charts  after  you  have  determined  the  function 
level  involved.  Figure  5-2  shows  partial  automation  to  assist  the  commander's 
decision  function.  It  indicates  that  the  information  flow  between  the  com¬ 
mander  and  the  staff  is  partly  through  an  automated  data  base  and  partly  man¬ 
ual.  For  example,  if  only  the  staff  estimates  and  the  commander's  guidance 
were  to  flow  between  commander  and  staff  via  automated  terminals,  any  addi¬ 
tional  decision  processing  by  the  commander  (additional  alternatives,  answering 
other  "what  if"  questions)  would  have  to  flow  over  the  manual  interfaces  indi¬ 
cated.  Figure  5-3  similarly  presents  the  middle  or  staff  processing  level  of 
the  C2  Information  processing/decision  making  system.  Figure  5-4  similarly 
presents  the  lower  layer,  i.e.,  the  input/output  and  pre-/post-decision  proc¬ 
esses  which  might  be  partially  automated  by  means  of  "electronic  mail."  Your 
flow  charts  are  not  finished  until  you  have  identified  every  information  trans¬ 
fer  across  each  automated  and  manual  interface  needed  for  the  product  under 
consideration.  A  technique  for  further  identifying  the  needed  interfaces  and 
displaying  them  is  discussed  in  Chapter  6.  A  logical  development  sequence  can 
now  be  determined  by  grouping  together  into  single  applications  those  products 
which  share  the  largest  number  of  automated  data  transfers.  Applications  can, 
in  turn,  be  sequenced  by  adding  them  in  the  sequence  which  provides  assistance 
to  the  largest  number  of  high  priority  products  with  the  smallest  addition  of 
automated  data  transfers. 

Several  things  will  be  noted  about  flow  charts  constructed  in  this  fashion: 

•  All  flow  charts  for  products  that  involve  the  same  functions  will  be 
essentially  identical;  the  differences  will  lie  in  the  needed  data  exchange. 

•  As  you  automate  more  and  more  products  in  one  of  the  large,  phased  ap¬ 
plications,  the  data  flow  will  tend  to  flow  more  and  more  over  the  automated 
channels  and  the  manual  exchanges  will  tend  to  disappear. 

«  Although  shown  as  separate  data  bases  for  each  of  the  function  levels, 
this  is  a  purely  functional  representation.  The  automated  data  bases  at  each 
level  need  not  be  physically  separated,  nor  physically  colocated  with  the  in¬ 
formation  functions  and  processes  they  support  (as  do  the  manual  data  bases). 
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MANUAL  OPERATION 


AUTOMATED  OPER ATI O N 
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MANUAL  INTERFACE 
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CHARACTERISTICS: 
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7 

CHARACTERISTICS: 


•  MANUAL  OPERATION  REQUIRES  COLOCATION 
OF  CMOR.  DATA  BASE.  &  STAFF 

•  HENCE.  CMDR'S  DECISION  FUNCTION 
MUST  BE  SCHEDULED  (DAILY  BRIEFINGS) 


•  LENDS  ITSELF  TO  DISPERSED  LOCATION 

•  HENCE,  CMDR  S  DECISION  FUNCTION  CAN 
BE  INVOKED  AS  REQUIRED  (CONTINUING 
ESTIMATE) 


Figure  5-2.  PARTIAL  AUTOMATION  —  CMDR’S  DECISION  FUNCTION 
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MANUAL  OPERATION 


AUTOMATED  OPERATION 


Figure  5-3.  PARTIAL  AUTOMATION  —  STAFF  DECISION  AND 
PRE-/POST-DECISION  FUNCTIONS 


MANUAL  OPERATION 


AUTOMATED  OPERATION 


EXTERNAL  INFORMATION  STREAM 


EXTERNAL  INFORMATION  STREAM 


Figure  5-4.  PARTIAL  AUTOMATION  —  PRE-/POST-OECISION  AND 
INPUT/OUTPUT  FUNCTIONS 
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5.4.  Total  System  Impact 


How  will  ADP  Application  Affect  SOP? 

Do  Redundant  Data  Bases  Increase  Workload? 

What  Effect  Does  Application  Have  on  Workload  Schedule? 

How  Does  Application  Affect  Task  Assignment? 

How  Does  Application  Affect  Workspace  Layout? 

How  Does  Application  Facilitate  TOC  Dispersion? 

How  Does  Application  Affect  Required  Communications? 

The  flow  charts  developed  as  described  above  are  also  very  useful  for  as¬ 
sessing  total  system  impact.  To  be  complete  they  should,  of  course,  include 
that  part  of  the  operation  that  remains  manual  as  well  as  that  which  is  pro¬ 
posed  for  automation.  One  needs  now  to  develop  a  detailed  SOP  for  system  op¬ 
eration  in  the  computer  assisted  mode  in  order  to  determine  how  automation 
affects  the  entire  operation.  In  some  cases  the  proposed  automation  could  add 
to  the  manual  workload,  e.g.,  by  requiring  personnel  to  maintain  duplicate  data 
bases,  or  Instead  of  smoothing  out  workload  it  could  cause  it  to  pile  up  at 
critical  nodes.  Careful  study  of  the  flow  chart  can  disclose  such  potential 
pitfalls  before  they  arise  in  actual  practice.  What  you  are  doing  here  is 
assessing  system  costs  that  are  outside  the  actual  automated  part  of  the  re¬ 
vised  system. 

Whenever  automation  is  used  to  process  information  continuously  rather  than 
a  scheduled  basis  (e.g.,  a  continuously  updated  appreciation  of  the  situation 
from  spot  reports  instead  of  periodic  summary  reports)  there  will  be  tendency 
to  smooth  out  peaks  in  the  loading. 

This  step  will  also  help  you  identify  changes  in  workload  and  needed 
changes  in  task  assignment  and  workspace  layout.  It  will  also  help  avoid  the 
fiasco  of  designing  a  system  more  difficult  to  operate  than  the  manual  mode. 

Carrying  out  these  steps  will  go  a  long  way  toward  insuring  a  smooth  tran¬ 
sition  to  computer  supported  operations  when  you  are  ready  to  bring  your  appli¬ 
cation  on  line  and  will  help  avoid  unpleasant  surprises  because  of  some  factor 
that  has  been  overlooked.  It  is  recognized  that  you  may  not  be  able  to  iden¬ 
tify  all  problems  at  this  stage  of  the  development  process.  However,  major 
problems  that  could  affect  system  operation  and/or  user  acceptance  should  be 
identified  at  this  time. 

Returning  to  the  Commander's  briefing  example,  the  remainder  of  this  sec¬ 
tion  examines  some  of  the  potential  impacts  of  automating  the  briefing  data 
base  on  the  rest  of  the  system. 
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5.4.1 


Changes  jn  Processing  Load 


In  the  manual,  twice-daily  briefing  mode,  the  interface  at  A  in  Figure  5-1 
(Commander-Briefing  Data  Base)  conaiats  of  two  diacrete  exchanges  per  day  be¬ 
tween  the  commander  (commander  group)  and  the  ataff  briefera.  Let'a  assume  in 
our  hypothetical  ataff  that  these  occur  at  0630  and  1830.  Obviously,  the  ataff 
must  start  building  its  briefing  data  base  some  time  prior  to  the  briefings. 

The  result  is  the  loading  of  the  ataff  and  of  the  communication  channels  which 
looks  something  like  Figure  5-5.  Sometime  prior  to  each  briefing  the  load 
peaks,  usually  at  channel  capacity.  (Did  you  ever  try  to  get  a  "flash"  message 
into  a  corps  TOC  about  30  minutes  before  the  evening  briefing?) 

Now  let's  consider  what  is  likely  to  happen  if  we  implement  the  commander's 
desire  to  automate  the  briefing  data  base  and  to  keep  it  continuously  current. 
The  staff  will  now  be  updating  the  briefing  data  base  (Interface  B  in  Figure 
5-1)  as  events  occur  and  interpretations  made.  The  commander  will  access  these 
data  and  staff  recommendations  and  enter  his  decisions  through  Interface  A. 
Because  the  staff  is  continuously  updating  the  briefing  data  base  —  at  the 
same  time  it  is  updating  its  own  —  the  processing  load  will  be  spread  out  over 
time  with  no  peaks  induced  by  scheduled  briefing  times.  Both  commo  and  staff 
activity  will  tend  to  follow  much  more  closely  the  tempo  of  combat  rather  than 
an  artificially  imposed  briefing  schedule. 

5.4.2.  Data  Base  and  Procedural  Changes 

A  new  digital  data  base  must  be  constructed  to  meet  the  commander's  brief¬ 
ing  needs.  Just  what  will  be  in  this  data  base  and  how  comprehensive  it  be¬ 
comes  depends  largely  on  which  of  the  commander's  decision  processes  it  is 
designed  to  support.  Let's  examine  two  extremes: 

•  Case  1 


The  commander  can  only  request  information  that  has  already  been  Inter¬ 
preted,  validated,  evaluated,  coordinated,  projected,  and  extrapolated  by  the 
staff.  He  can  evaluate  only  alternatives  already  generated  by  the  staff  and 
the  computer  provides  no  help  in  their  evaluation,  i.e.,  he  has  no  capability 
to  use  the  computer  to  generate  answers  to  "wh8t  if"  questions. 

•  Case  2 


As  the  other  extreme,  the  commander  has  the  capability  of  conducting  a 
dialogue  with  the  computer.  He  can  query  to  get  the  additional  information 
needed  for  his  personal  interpretation,  validation,  and  coordination  just  as  he 
might  during  repartee  at  the  briefing.  He  can  ask  the  computer  to  project 
current  trends  and  to  make  extrapolations  as  to  likely  future  situations.  He 
can  enter  new  alternatives  not  considered  by  the  staff  and  evaluate  the  proba¬ 
ble  outcome  of  various  "what  if"  questions.  In  other  words  the  computer  sup¬ 
port  has  become  a  true  decision  aid. 

Now  let's  examine  the  Impact  of  these  two  extremes  on  the  operation  of  the 
TOC.  For  Case  1  the  commander’s  briefing  data  base  will  be  a  compilation  of 
relatively  small  subsets  of  the  data  contained  in  the  various  staff  section 
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files.  The  only  information  that  the  staff  sections  will  retrieve  from  the 
briefing  data  base  will  be  any  decisions  entered  by  the  commander  and  they 
might  use  it  to  refresh  their  memories  as  to  "what  did  we  last  tell  the  old 
man"?  There  will  be  very  little  tendency  for  the  staff  sections  to  view  the 
briefing  data  base  as  being  in  any  way  a  substitute  for  their  own  section  data 
base.  The  operation  continues  essentially  as  shown  in  Figure  5-1. 

For  Case  2  an  entirely  different  situation  will  prevail.  The  briefing  data 
base  will  tend  to  contait.  more  and  more  information  as  the  commander  probes 
deeper  into  what  the  staff  is  telling  him.  As  it  grows  the  staff  will  discover 
how  much  faster  and  easier  it  is  to  retrieve  the  Information  they  need  for 
their  own  decision  processes  from  the  briefing  data  base  rather  than  from  their 
own  files.  Also,  they  can  hardly  be  prevented  (nor  should  they)  from  using  the 
computer's  capability  to  answer  "what  if"  questions  for  their  own  staff  deci¬ 
sion  making.  The  result  of  this  will  be  that  the  staff  will  ignore  its  manu¬ 
ally  maintained,  perceived  data  base  and  rely  more  and  more  on  what  is  the,  now 
automated,  briefing  data  base.  Figure  5-6  illustrates  what  has  happened  and 
shows  the  changes  that  have  taken  place  in  the  original  TOC  operation  depicted 
in  Figure  5-1.  The  separate  staff  section  data  bases  have  completely  disap¬ 
peared.  All  sections  and  the  commander  now  rely  on  a  common  perceived  and 
automated  data  base.  Interface  B  (STAFF-BRFG  Data  Base),  which  previously 
Incorporated  the  transition  from  manual  to  digital  data  is  now  completely  digi¬ 
tal;  interface  C  (STAFF-Section  Data  Base)  has  disappeared  or  it  can  be  viewed 
as  having  been  incorporated  into  Interface  B.  The  transition  of  manual  to 
digital  has  now  shifted  to  Interface  D  (Pre-Post  Decision-Automated  Data  Base). 
All  of  the  staff  section  information  processing  above  the  input  and  output 
functions  is  being  computer  assisted.  Surely,  this  represents  a  major  change 
in  the  TOC  operation  and  will  require  very  careful  review  of  SOPs. 

5.4.3.  Dispersed  Operations 

The  discussion  up  to  this  point  has  been  on  a  purely  functional  basis; 
nothing  has  been  said  about  the  physical  location  of  either  the  Information 
processes  or  the  data  bases.  The  third  major  potential  Impact  of  computer 
support  is  on  the  location  of  the  various  TOC  activities.  The  ever  broadening 
scope  of  the  battlefield,  both  in  terms  of  its  size  and  the  variety  of  sensors 
and  weapons  to  be  controlled  and  coordinated,  coupled  with  the  ever  increasing 
pace  of  modern  warfare  have  caused  us  to  depend  on  larger  and  larger  amounts  of 
data.  But  we  still  have  the  same  human  limitations  on  the  number  of  different 
factors  that  we  can  juggle  simultaneously  in  making  tactical  decisions.  We 
must  depend  Increasingly  on  memory  extenders  (displays  and  files)  and  on  infor¬ 
mation  processing  by  others  to  aggregate,  concentrate,  and  Identify  key  factors 
to  be  considered  in  our  decision  making.  If  we  do  this  manually  we  are  physi¬ 
cally  tied  to  our  information  processing  system.  Staff  sections  are  tied  to 
their  manual  data  bases.  When  they  move  the  data  base  deteriorates  rapidly  and 
is  not  again  usable  until  some  time  after  they  have  gone  back  on-line  and  begun 
the  slow  process  of  updating  it  by  hand.  It  takes  significant  time  intervals 
to  transfer  current  data  from  Alternate  to  Main  and  vice  versa  when  we  must 
depend  an  voice  communication  channels  to  make  the  transfer.  Similarly,  if  the 
Information  collected  and  processed  by  the  staff  is  presented  to  the  commander 
by  means  of  visual  displays  at  briefings,  all  must  be  colocated  —  usually  in 
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the  vicinity  of  the  TOC.  For  much  the  same  reasons,  if  the  separate  staff 
section  data  bases  are  to  stay  coordinated  they  must  also  be  colocated  —  again 
in  the  TOC. 

Operating  in  the  mode  of  Figure  5-6  is,  however,  quite  a  different  story. 
Not  only  can  the  commander  be  located  remotely  from  the  common  data  base  and 
still  access  the  information  he  needs  through  automated  Interface  "A",  but  the 
staff  sections  can  also  be  separately  located,  communicating  with  the  common 
data  base  through  automated  interfaces  nB-C"  and  nDn.  Also  the  common  data 
base,  shown  in  the  figure  as  a  single  functional  entity,  need  not  be  all  in  one 
place.  It,  too,  can  be  distributed  among  several  locations  reducing  still  fur¬ 
ther  the  vulnerability  of  the  TOC.  All  this  is  subject  to  two  caveats.  First, 
the  physically  separated  functional  components  and  data  bases  must  be  intercon¬ 
nected  with  a  network  of  digital  communication  which  can  also  be  made  quite 
resistant  to  enemy  Interference  through  netting  and  automatic  switching.  Sec¬ 
ond,  digital  communication  can  replace  a  major  fraction  of  current  voice  commu¬ 
nication,  but  it  can  never  replace  it  entirely.  Some  voice  communication  must 
be  provided  to  fill  the  very  human  need  for  human  interaction  in  times  of 
stress. 


CHAPTER  6: 


REQUIREMENT  DEFINITION 


o 

It  has  been  shown  that  C  operations  may  be  considered  as  an  information 
processing  system  composed  of  a  number  of  components,  in  our  case,  functions 
and  databases,  which  receive  information  either  from  another  component  or  from 
the  external  world,  process  that  information,  and  then  transmit  information  to 
another  component  or  to  the  external  message  stream.  To  facilitate  communica¬ 
tion  between  the  field  user,  who  is  an  expert  in  C2  operations  and  best  under¬ 
stands  the  automation  concept,  and  the  technicians,  who  must  build  the  system, 
it  is  necessary  for  the  user  to  precisely  specify  the  information  flow  require¬ 
ments  for  the  automated  system.  This  is  accomplished  by  identifying  each  of 
the  system  components,  describing  the  processing  it  must  do,  and  specifying  the 
nature  and  amount  of  information  to  be  transferred  between  components. 

If  the  application  is  relatively  simple,  the  requirement  definition  may  be 
done  directly.  In  most  cases,  however,  it  is  worthwhile  to  impose  a  measure  of 
organization  on  the  definition  process.  A  uaeful  technique  for  organizing  the 
task  is  called  the  N2  chart.  It  is  a  technique  used  by  systems  analysts  in 
designing  automated  system  architecture,  but  is  equally  useful  to  you  in  your 
capacity  as  the  total  (human/machine)  system  designer. 

P 

In  a  sense,  the  N  chart  is  the  complement  to  the  flow  charts  with  which 
you  are  already  familiar.  Flow  charts  are  built  up  of  components  (functions 
and  data  bases)  and  arrows  connecting  these  to  show  the  Information  flow  be¬ 
tween  them.  Hence  a  flow  chart  tends  to  emphasize  functions  and  data  bases. 

The  N2  chart,  as  you  will  see,  emphasizes  the  interfaces  (Information  trans¬ 
fers)  between  components. 

You  don't  have  to  draw  too  many  flow  charts  before  you  realize  that  the 
placement  of  the  boxes  representing  the  components  is  critical  if  you  want  to 
avoid  confusion  and  crossovers  when  drawing  the  Interface  arrows.  This  is 
especially  true  if  there  are  many  such  interconnections.  If,  however,  we  draw 
the  function  and  data  base  boxes  along  the  main  diagonal  of  a  large  square, 
then  every  other  small  square  off  the  diagonal  represents  a  potential  interface 
between  a  pair  of  components.  By  convention,  the  off-diagonal  box  represents 
information  which  flows  from  the  component  on  the  same  row  Jto  the  component  in 
the  same  column.  Figure  6-1  Illustrates  with  an  N2  chart  of  3  components.  As 
can  be  seen,  there  are  two  small  boxes  for  each  possible  pair  of  components, 
one  box  for  each  of  the  two  possible  directions  of  information  flow.  The  box 
labeled  number  1  in  Figure  6-1,  for  example,  represents  information  flow  from 
component  1  to  component  3.  while  the  box  labeled  number  2  represents  informa¬ 
tion  transfer  from  component  2  to  component  1. 


50 


r 


ruNCTio* 

l 

-a®; 

f3  ' 

:®  * 

rune T ION 

2 

lr2 ) 

! 

r3  ' 

i  5 

i  Lf' 

1 

njKCTION 

3 

<r3) 

L _ 

L 

Figure  6-1.  Sample  N2  Chart 


This  la  easier  to  understand  If  we  use  a  concrete  example.  Figure  6-2  Is 
the  N2  chart  corresponding  to  the  flow  chart  of  the  operation  section's  proc¬ 
essing  contribution  to  the  commander's  briefing  shown  at  Figure  5-1.  The  lat¬ 
ter  shows  nine  major  components  to  be  considered  for  the  commander's  briefing, 
so  Figure  6-2  shows  a  9  X  9  matrix  with  the  function/data  base  boxes  drawn  as 
solid  squares  along  the  diagonal.  All  the  other  boxes  in  the  matrix  are  out¬ 
lined  by  dotted  lines  and  represent  all  of  the  possible  Interfaces  between  the 
nine  major  components.  There  are  9X9=81-9=72  such  potential  inter¬ 
faces.  Granted,  not  all  of  these  will  actually  exist,  but  the  advantage  of 
the  N2  chart  is  that  it  reminds  you  that  they  can  and  makes  you  justify  every 
empty  Interface  box  where  no  interface  occurs.  Where  an  interface  between 
components  actually  occurs  a  circle  has  been  entered  into  the  dotted  square  and 
the  direction  of  information  flow  is  indicated  by  an  arrow.  The  same  names 
have  been  entered  in  the  diagonal  component  boxes  as  are  used  in  Figure  5-1. 

The  Interface  entries  have  been  numbered  and  the  letter  used  to  identify  the 
interfaces  in  Figure  5-1  has  also  been  entered  near  the  bottom  of  each  circle 
in  the  Interface  boxes.  Note  that  the  N2  chart  has  reminded  us  of  four  inter¬ 
faces  which  are  Ignored  in  Figure  5-1  so  that  four  circles  (3,  k,  5,  and  17) 
contain  no  letters.  These  represent  the  distinct  possibility  that  pre-and 
post-processing  may  need  to  retrieve  previously  filed  whole  messages  from  the 
raw  data  base. 

To  continue  the  example,  note  that  the  flow  shown  in  Figure  5-1  represents 
Case  1  (see  Section  5. *1.2.}  in  which  the  automated  briefing  data  base  (labeled 
BRIEFING  SOFTWARE  in  Figure  5-1)  provides  the  commander  only  selected  pre¬ 
decision  processed  Informstion  end  information  subjected  to  the  stsff  decision 
processes.  It  does  not  sssist  his  own  decision  msking  by  silowing  him  to  re¬ 
pest  or  expend  staff  decision  processing  by  ssklng  "whet  If  questions  of  the 
BRIEFING  SOFTWARE.  Only  four  man/mschlne  interfsces  ere  shown  on  the  chert 
(11,  13,  Ik,  end  16)  and  these  have  been  marked  with  asterisks.  These  sre 
functional  deslgnstions;  11  end  13  would  actually  be  multiple  terminals  for  the 
several  staff  sections. 
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Figure  6-2.  N2  CHART  OF  THE  COMMANDER’S  BRIEFMG 
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Table  6-1  can  now  be  developed  from  the  N*  chart.  It  describes  each  of  the 
major  components  and  then  describes  the  nature  of  every  Information  exchange, 
l.e.,  the  Inputs  to  the  TOC,  the  numbered  Interfaces,  and  the  TOC  outputs. 

Since  all  but  four  of  the  numbered  Interfaces  represent  manual  data  exchanges, 
these  descriptions  are  In  very  general  terms.  In  this  connection  the  term 
"processed  Information"  la  shorthand  for  the  Information  produced  by  the  pre- 
and  post-decision  functions  and  "manipulated  Information”  Is  shorthand  for  the 
output  of  the  decision  processes.  The  latter  is  distinguished  by  the  fact  that 
the  decision  processes  contain  Information  that  was  not  contained  in  the  in¬ 
coming  message  stream  (hypotheses,  Interpretations,  extrapolations,  etc.).  It 
Is  when  we  come  to  the  man-machine  Interface  descriptions  that  requirements 
definition  really  begins.  The  power  of  the  techniques  springs  from  the  fact 
that,  once  the  inputs  and  outputs  to  the  automated  portion  of  the  system  have 
been  adequately  described,  the  technician  can  (with  the  operator-user's  help) 
organize  the  needed  data  base  and  define  the  algorithms  needed  to  convert  Input 
Into  output.  For  the  present  example  this  conversion  Is  fairly  simple,  al¬ 
though  outputs  may  well  be  In  different  format  from  Inputs  —  or  even  provide  a 
capability  to  construct  new  formats  from  scratch. 


The  descriptions  of  the  four  automated  Interfaces  shown  In  Table  6-1  are 
only  the  beginning.  These  must  now  be  expanded  to  Include  every  element  of 
data  to  be  transferable  from  staff  to  commander  Bnd  return  through  the  auto¬ 
mated  terminals  and  every  format  to  be  employed.  If  self-formatting  Is  to  be 
available,  the  range  of  such  formatting  must  be  agreed  upon.  You  will  note 
that  Interfaces  15  and  12  provide  the  loop  from  commander  to  staff  around  the 
automated  system.  Since  you  cannot  and  do  not  desire  to  atop  the  commander 
from  asking  questions  he  cannot  get  answered  through  the  automated  terminal.  It 
is  this  route  that  will  be  taken  to  get  such  Information  by  voice  communica¬ 
tions.  In  deciding  what  Information  to  transmit  through  the  terminal,  you  are 
making  a  trade-off  between  these  two  means  of  communication,  and  you  are  adding 
to  the  workload  Involved  In  STAFF  DECISION  by  requiring  the  staff  to  maintain 
two  data  bases.  You  will  also  note  that  this  loop  provides  the  back-up  in  case 
the  automated  system  goes  down  —  It  represents  the  original  manual  way  of 
conducting  the  briefing. 


Using  this  technique  the  user  and  technician  working  together  can  develop  a 
statement  that  both  understand  and  that  avoids  many  of  the  gaps  that  all  too 
frequently  plague  requirements  drafted  without  dual  participation. 
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Table  6-1 


Functional,  Manual  Data  Base,  and  Interface  Descriptions  for  the 
Commander 'a  Briefing 

Functional  and  Manual  Data  Base  Descriptions 
Input 

a  Receives,  verifies,  and  tags  incoming  messages 

•  Enters  messages  in  RAW  DATA  BASE 
e  Passes  messages  to  PRE-DECISION 

Raw  Data  Base  (Manual) 

•  Stores  messages  in  retrievable  form 

a  Retrieves  and  passes  selected  messages  to  PRE-POST-DECISION 
Pre-Decision  Processing 

•  Sorts,  associates,  and  aggregates/organizes  information 

•  Files  processed  information  in  PROCESSED  DATA  BASE  (manual) 

•  Queries  RAW  DATA  BASE  for  selected  messages 
Processed  Data  Base  (Manual) 

•  Stores  processed  information  in  retrievable  form 

•  Provides  information  to  PRE-POST-DECISION 

•  Stores  manipulated  information  from  STAFF  DECISION 

a  Provides  processed  and  manipulated  information  to  STAFF  DECISION 
Staff  Decision 

a  Ratrievea  processed  and  manipulated  data  from  PROCESSED  DATA  BASE 
a  Files  manipulated  data  in  PROCESSED  DATA  BASE 

a  Files  processed  and  manipulated  data  to  BRIEFING  SOFTWARE  through 
terminal 
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Table  6-1  (Continued) 


a  Provides  processed  and  manipulated  data  to  COMMANDER  DECISION  by 
voice  commo  In  response  to  queries 

•  Receives  queries  from  COMMANDER  DECISION  by  voice  commo 
Briefing  Software 

•  Stores  processed  and  manipulated  data  received  from  STAFF  DECISION 
through  terminal 

•  Responds  to  queries  received  from  STAFF  DECISION  and  COMMANDER 
DECISION  through  terminals 

a  Provides  processed  and  manipulated  information  to  STAFF  DECISION 
and  COMMANDER  DECISION  in  response  to  queries  through  terminal 

Commander  Decision 

a  Receives  processed  and  manipulated  Information  from  BRIEFING  SOFTWARE 
through  terminal 

a  Receives  processed  and  manipulated  Information  from  STAFF  DECISION 
by  voice  commo 

•  Queries  BRIEFING  SOFTWARE  and  sortes  manipulated  Information  there 
(Including  decisions)  through  terminal 

a  Queries  STAFF  DECISION  and  announces  decisions  by  voice  commo 

Post-Decision 

a  Receives  processed  and  manipulated  data  from  PROCESSED  DATA  BASE 
a  Receives  selected  messages  from  RAW  DATA  BASE 
a  Queries  PROCESSED  DATA  BASE  for  selected  Information 
a*  Files  processed  Information  in  PROCESSED  DATA  BASE 
a  Queries  RAW  DATA  BASE  for  selected  messages 
a  Composes  outgoing  messages  and  forwards  to  OUTPUT 
Output 

a  Flies  outgoing  messages  In  RAW  DATA  BASE 
a  Transmits,  verifies,  and  tags  outgoing  messages 
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Table  6-1  (Continued) 


Inputs 

•  Incoming  communications  traffic 
Interfaces 

1.  Incoming  messages 

2.  Incoming  messages 

3.  Selected  whole  messages 

4.  Selected  whole  messages 

5.  Requests  for  selected  messages 

6.  Processed  information  and  requests  for  stored  Information 

7.  Requested  information 

8.  Requested  information 

9.  Requested  Information 

10.  Manipulated  Information 

11.  "Selected  Information  in  following  categories: 

•  Weather  data  and  extrapolations 

•  Terrain  data  and  extrapolations 

•  Friendly  unit  locations,  status,  capabilities 
e  Enemy  unit  locations,  status,  capabilities 

e  Mission 

•  Organization  for  Combat 
e  Order  of  Battle 

•  Logistic  Status 

•  Adml n  Status 

•  Courses  of  action  considered 
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Table  6-1  (Continued) 


r 


•  Enemy  lntentions/capabllltles  considered 

•  Staff  recommendations 

•  Staff  requests  for  any  of  above  or  for  commander's  entries 

12.  Staff  responses  to  commander's  requests  for  Information  not  avail¬ 
able  from  BRIEFING  SOFTWARE 

13.  "Selected  information  In  following  categories: 

•  Commander's  planning  guidance  and  decisions  entered  at  Interface 
16 

•  Any  categories  entered  at  Interface  11 

14.  "Selected  Information  In  following  categories: 

•  Any  categories  entered  at  Interface  11 

•  Commander's  planning  guidance  and  decisions  entered  at  Interface 
16 

15.  •  Requests  to  staff  for  Information  not  available  from  BRIEFING 

SOFTWARE;  planning  guidance  and  decisions  not  enterable  at 
Interface  16 

16.  "Selected  Information  In  following  categories: 

•  Requests  for  any  categories  entered  at  Interface  11 

•  Requests  for  previously  entered  commander's  planning  guidance  and 
decisions 

17.  Requests  for  selected  messages 

18.  Processed  information  and  requests  for  stored  Information 

19.  Outgoing  messages 

20.  Outgoing  messages 
Outputs 

•  Outgoing  communications  traffic 
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CHAPTER  7: 


CONDUCTING  THE  DEMONSTRATION  AND  TRIALS 


The  initial  demonstration  and  trials  is  the  most  important  milestone  in  the 
entire  effort.  If  the  commander  and  senior  staff  do  not  have  the  impression 
that  computer  support  can  Improve  their  C^  operation,  the  entire  effort  is 
clearly  in  trouble.  Here  are  a  few  rules  that  will  help  avoid  that  outcome. 


1.  Involve  the  users  during  the  software  development  phase.  During  soft¬ 
ware  development,  the  user  is  needed  to  provide  advice  and  guidance  to  the 
technician,  to  confer  on  what  the  user  will  find  acceptable,  to  evaluate  the 
proposed  Interfaces  —  especially,  displays,  and  to  be  available  for  "hands-on" 
training  especially  for  the  operators  of  the  equipment.  Don't  forget  that  in 
the  example  cited  above  the  principal  operators  are  the  commander  and  the  sen¬ 
ior  staff.  These  operators  should  be  exposed  to  the  automated  support  almost 
as  soon  as  the  first  displays  can  be  brought  up  on  the  equipment.  Do  not  wait 
until  the  system  is  ready  to  be  operated  in  the  field.  Initial  exposure  should 
be  in  garrison  and  should  be  continuing  throughout  the  development  phase.  In 
addition  to  giving  the  future  operators  experience  and  confidence  in  computer 
support,  thus  minimizing  "computer  anxiety"  (the  fear  of  bringing  the  whole 
system  down  or  looking  foolish  before  others  because  of  a  stupid  mistake)  this 
early  user  Involvement  will  pay  tremendous  dividends  in  fielding  a  more  usable 
system  and  insuring  much  earlier  user  acceptance. 


2.  A  thorough  and  complete  plan  for  the  demonstration  and  trials  must  have 
been  completed  while  the  proposed  computer  support  was  being  developed.  Plan¬ 
ning  for  the  initial  trials  is  somewhat  similar  to  planning  for  an  FTX  or  a  map 
exercise.  The  scale  of  the  trials  will  be  determined  by  the  nature  of  the 
applications  being  tested.  Trying  out  a  movement  order  generator  does  not 
require  a  full-blown  CPX;  trial  of  an  automated  briefing  system  probably  does 
—  at  least  a  reduced  scale  exercise  on  the  grounds  of  home  station.  There 
must  be  means  for  providing  an  Information  load  to  the  system.  How  elaborate 
this  Is  again  depends  on  the  application  being  tested.  This  could  range  from  a 
simple  scenario  to  a  full-blown  Master  Incident  List  to  a  battle  simulation. 


You  must  begin  with  a  set  of  test  objectives  tied  directly  to  the  changes 
in  (r  performance  sought  by  means  of  the  automation  support  being  tested. 

These  will  Indicate  the  nature  and  extent  of  the  combat  environment  to  be  simu¬ 
lated  In  order  to  load  the  TOC  if  the  application  Is  tactical,  and  to  provide 
the  information  needed  to  generate  the  products  to  be  tested.  In  addition  to 
fielding  the  TOC,  the  plan  must  also  provide  for  the  umpires  or  controllers 
necessary  for  simulating  the  battle  events  and  for  the  data  collectors  neces¬ 
sary  to  gather  the  quantitative  measures  of  goal  achievement. 


3.  Remember  that  you  are  conducting  an  experiment;  good  experimentation 
requires  a  controlled  environment.  This  means  you  must  minimize  the  effects 
of  all  variables  except  those  you  are  trying  to  measure.  This  second  rule  is 
probably  the  one  most  difficult  to  apply.  Whenever  any  tactical  exercise  Is 
proposed  there  Is  always  the  tendency  to  add  as  many  training  objectives  as 
possible.  This  must  be  avoided  for  the  Initial  trials  and  Is  another  reason 
for  the  personal  involvement  of  the  oommander  and  senior  staff.  The  activity 
most  closely  tied  to  C 2  is,  of  course,  communication,  but  discovering  the 
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training  deficiencies  of  the  signal  battalion  or  brigade  is  not  the  objective 
of  the  initial  trials  of  the  computer  support  application.  The  initial  trial 
should  take  place  in  garrison  or  with  hard  wired,  reduced  distance  comuni  ca¬ 
tion  so  that  the  disturbing  effects  of  everything  but  the  computer  support  of 
operations  is  held  to  a  minimum.  Later  experimentation  with  alternative  commu¬ 
nication  nets  is  certainly  warranted  to  discover  optimal  C2  configurations,  but 
the  initial  trials  of  a  new  automation  application  must  eliminate  as  far  as 
possible  the  uncontrolled  variables  of  a  full-blown  communication  system.  The 
same  principle  applies  to  any  other  possible  source  of  impact  on  the  C2  system. 
The  objective  of  the  initial  trials  must  be  to  measure  the  change  in  perform¬ 
ance  result! ng  from  the  computer  support  to  C2  operations  —don't  dilute  it  by 
trying  to  determine  the  effect  of  other  changes.  Reducing  the  scale  of  the 
exercise  to  the  minimum  needed  to  reach  that  objective  will  reduce  the  expendi¬ 
ture  of  limited  training  funds  and,  thus,  the  pressure  to  add  training  objec¬ 
tives. 

4.  A  detailed  SOP  for  use  with  the  computer  support  must  have  been  devel¬ 
oped;  the  initial  trials  are  a  teat  of  that  SOP  as  well  as  of  the  computer 
support.  You  will  already  have  initiated  compliance  with  the  third  rule  when 
you  analyzed  the  total  system  impact  of  automation,  especially  the  initial 
increment,  during  the  concept  development.  Looking  at  the  changes  in  SOP  in¬ 
evitably  associated  with  your  initial  application  was  part  of  that  exercise. 
This  needs  to  be  extended  and  modified  as  the  development  proceeds  to  take  into 
account  the  inevitable  changes  in  requirements  and  new  insights  provided  as  the 
user  gets  involved  during  the  development  phase.  The  important  point  is  that 
everyone  involved  must  have  a  clear  idea  of  what  the  application  is  to  be  used 
for,  who  operates  the  equipment,  and  how  it  is  to  be  employed.  Well  trained 
equipment  operators  who  have  already  had  extensive  experience  with  the  equip¬ 
ment  in  garrison  are  part  and  parcel  of  this  rule. 

5.  The  entire  staff  (not  just  the  operators  and  data  collectors)  must  have 
been  oriented  in  advance  as  to  the  test  objectives,  the  goals  of  the  effort, 
and  the  measures  of  accomplishment.  The  entire  staff  —  that  is,  everyone 
involved  in  the  trials  —  must  be  oriented  on  what  the  demonstration  and  trials 
are  all  about.  Not  only  will  this  improve  the  trial,  but  it  Is  amazing  what 
insights  toward  improvement  of  the  whole  operation  can  be  provided  by  knowl¬ 
edgeable  persons  who  have  been  adequately  briefed  even  though  not  immediately 
associated  with  the  computer  support.  This  rule  also  reinforces  the  importance 
of  the  operating  principle  stated  previously,  namely,  that  automation  must  be 
phased  iq  gradually  in  steps  sufficiently  small  that  they  can  be  absorbed  by 
the  staff  without  completely  changing  their  method  of  operation  in  one  fell 
swoop.  Nothing  can  be  more  devastating  to  acceptance  of  computer  support  than 
trying  to  impose  too  much  change  in  the  first  step. 

A  major  purpose  of  this  manual  is  to  assist  yot  in  gaining  initial  and 
maintaining  continuing  acceptance  of  the  new  modes  of  operation  that  inevitably 
will  accompany  the  introduction  and  assimilation  of  automation  into  your  unit 
C2  operations. 

The  following  set  of  principles  summarizes  the  experience  of  others  in 
making  this  transition  successfully: 
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•  Too  aust  inspire  confidence  in  the  ability  of  autoaated  hardware  and 
software  to  assist  in  tactical  operations.  Don't  bite  off  tore  than  you  can 
chew  initially;  it  is  far  better  to  have  people  panting  for  the  next  applica¬ 
tion  than  to  awaap  thea  with  aore  than  they  can  absorb. 

a  You  auat  avoid  even  the  appearance  of  adding  to  the  workload;  "If  it 
doesn't  aake  ay  job  easier,  it's  no  good." 

e  You  auat  overcoae  "ooaputer  anxiety"  by  exposing  the  ultlaate  operator 
to  the  equipment  aa  soon  a a  possible.  He  auat  be  thoroughly  f aai 1 1 ar  with  it 
prior  to  the  initial  daaooatratlon  and  trials. 

e  While  you  auat  not  let  coaaunl catl on  difficulties  unduly  affect  your 
initial  deaonatratlon  and  trials,  you  auat  be  ever  aware  that  the  ultlaate 
constraints  laposed  by  you r  coaaunlcation  net  auat  be  considered  in  your  total 
coaaand  and  oontrol  syatea  design. 

Faalllsrlty  with,  and  confidence  in  a  ayatea  aeea  to  be  the  prlaary  factors 
in  user  acceptance  —  that  is,  aasuaing  the  aystea's  utility  in  aiding  user 
functions  has  been  perceived.  If  the  ayatea  is  perceived  to  create  additional 
workload,  user  resistance  will  be  difficult  to  overcoae. 

When  the  users  becoae  aware  of  now  the  ayatea  will  assist  thea  in  the  per- 
foraanoe  of  their  Jobs,  the  next  hurdle  aeeaa  to  be  overcoalng  "coaputer  anxi¬ 
ety."  Developing  a  faaillarlty  with  the  ooaputer  to  overcoae  these  fears  Is  the 
first  step  in  training.  Training  cannot  be  effective  until  the  user  la  at  ease 
and  ooafortable  with  the  aachlne.  In  aany  cases  aoae  portion  of  the  applica¬ 
tion  already  developed  will  be  applicable  to  peacetiae  operations  in  garrison. 
This  use  should  be  encouraged  and  will  greatly  aid  in  gaining  user  acceptance. 

Another  aa  Jar  factor  in  user  acceptance  is  confidence  in  the  ayatea.  This 
is  related  to  perception  of  utility.  When  the  users  are  not  confident  in  the 
ayatea  they  take  precautions  against  its  failure,  i.e.,  aalntaln  the  annual 
ayatea  also.  This  creates  additional  work  and  the  ooaputer,  because  of  its 
perceived  lack  of  reliability,  la  blsaed  for  the  Increase.  To  aoae  extent 
increased  faaillarlty  will  lead  to  increased  confidence;  however,  the  ayatea 
auat,  in  fact,  be  reliable.  Periodic  failures,  loss  of  data,  and  nonavail¬ 
ability  when  needed  will  be  aaplifled  In  the  Bind  of  the  user  and  auat  be  aini- 
alsed  to  develop  confidence  that  the  ayatea  la,  and  will  be  a  worthwhile  tool 
for  the  user . 

The  user ' a  exposure  to  the  ooaputer  syatea  auat  be  continuous  in  order  to 
develop  and  aaiatain  faalllsrlty  with  its  use.  Syatea  applications  Bust  be 
developed  for  use  in  garrison  to  facilitate  this.  A  ayatea  which  is  used  only 
in  field  operations  oreates  a  training/ relearning  problaa  prior  to  and  in  the 
early  stages  of  every  eaerelae.  "User  friendly"  la  a  catchy  phrase  irtilch  has 
different  aa an logs  far  different  people  and  always  requires  traaandoua  overhead 
within  the  ooaputer  ayatea.  We  are  a  long  way  froa  having  ooaputer  ayateadi 
which  oan  carry  an  huash-1 I ke  conversations  and,  therefore,  are  forced  to 
learn  to  talk  to  the  ooaputer  in  ways  It  can  istderatand.  If  we  espect  the 
coaputer  to  be  of  use  in  a  "ooae  aa  you  are"  war,  users  auat  be  totally  faaii- 
iar  with  and  ooafortable  with  the  ayatea.  There  will  be  no  tloe  to  get  up  to 
speed  in  its  use. 


Coaaun teat ions  capability  la  rapidly  becoming  the  Halting  factor  in  the 
transfer  or  exchange  of  data  in  organ! rations  using  automated  data  systeas.  In 
order  to  realize  the  full  benefit  of  ooaputera,  data  aust  be  transferred  be¬ 
tween  locations  rapidly.  Decision  support  In  tactical  command  and  control  can 
require  large  data  transfers,  especially  when  such  transfers  are  not  Halted 
to  the  dynaaic  data  eleaents  and  Include  large  blocks  or  relatively  stationary 
data  which  could  have  been  stored  locally.  It  has  becoae  evident  in  some  of 
the  initiatives  that  hand  carrying  large  files  on  magnetic  disk  could  relieve 
systea  congestion  and  even  save  tiae  in  the  transfer.  Possibilities  for  commu¬ 
nication  upgrades  must  be  exaalned  and  fielded  to  take  Tull  advantage  of  the 
autoawted  data  capabilities. 
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